From owner-ietf-fax@imc.org Wed Mar 1 17:08:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14453 for ; Wed, 1 Mar 2000 17:08:15 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA08795 for ietf-fax-bks; Wed, 1 Mar 2000 13:20:51 -0800 (PST) Received: from mis2.centigram.com (pix78.centigram.com [198.137.183.78]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08791 for ; Wed, 1 Mar 2000 13:20:50 -0800 (PST) From: Eric.Burger@centigram.com Received: from notes.centigram.com (notes.centigram.com [129.1.11.64]) by mis2.centigram.com (8.9.1/8.9.1) with SMTP id NAA08809; Wed, 1 Mar 2000 13:20:10 -0800 (PST) Received: by notes.centigram.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 88256895.0075465C ; Wed, 1 Mar 2000 13:20:57 -0800 X-Lotus-FromDomain: CENTIGRAM To: vpim@lists.neystadt.org, ietf-fax@imc.org Message-ID: <88256895.0075456F.00@notes.centigram.com> Date: Wed, 1 Mar 2000 13:23:01 -0800 Subject: Re: draft-ema-vpim-pndn-00/01.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Comments in-line. Graham Klyne on 02/17/2000 02:39 PM GMT wrote: > At 02:55 PM 2/15/00 -0800, Eric.Burger@centigram.com wrote: > >Document: draft-ema-vpim-pndn-01.txt February 15, > >2000 > > > > Partial Non-Delivery Notification > > Eric, > > I thought this read very well. Even the bits I would have been inclined to > disagree with, I found to be well-justified. > > I have a few minor comments. > > Firstly: a process matter: this was announced by the IETF as draft > version -00? Is this really correct? Was the -00 version never published > as an I-D? You are absolutely correct. The RFC editors changed the -01 to -00. I'm submitting a new draft incorporating the following changes, as well as a few formatting bug fixes, as -01. > [Page 4:] > > > NOTE: An alternative method of handling partial delivery is to > > determine what parts of the message the sender considers critical. > > "alternative" here seems to imply mutual exclusion. I would prefer, say, > "An additional method ...". How about "NOTE: Another method..." [snip] > > delivered message. The VPIM work group determined this method, in > > practice, would be too complex to implement and would have the > > drawback of the voice mail system silently deleting message > > components. In light of the limitations of voice mail systems, we [snip] > You say "The VPIM work group determined ...". Is this true? I don't > recall seeing this particular point discussed on the mailing list; did I > miss someting? We didn't discuss this on the list. I'll take the hit for that. We discussed it at the EMA VPIM meeting in November. That was my interpretation of the discussion. However, it's not that clear looking at the meeting minutes. How about this language: the delivered message. However, currently there is no method to identify critical parts. In light of the limitations of voice mail ... What I'm really saying is that until there is a critical-part mechanism, there's nothing available to us other than PNDN's. > > [...] > >5.3.4. Original Content ID Field > >5.3.5. Original Content Description Field > >5.3.6. Original Content Disposition Field > >5.3.7. Original Content Type Field > > > > This field, if present in the original message, MUST be present in > > the PNDN. > > Similarly: "... if a 'Content-type' field is present in the original message." Excellent English. I've incorporated the re-organized sentence structure. Note I've expanded the Original-Content-Disposition paragraph to be more clear, as well: # The Original-Content-Disposition field MAY be present in the PNDN # if a Content-Disposition field is present in the original message. # If the original message does not have a Content-Type field, the # Original-Content-Disposition field MUST be present in the PNDN # if a Content-Disposition field is present in the original message. # The Original-Content-Disposition field aids the sender in # understanding exactly which body part the receiving system is # not capable of delivering. This field will be more useful than # the Original-Content-ID field to a human sender. It will let the # human know the file name of the part the receiving system is # not capable of handling. > > >5.3.8. Status Field > > > > [...] > > Define status values here (or put in placeholders for them)? > > (I think the approach of defining the status value(s) in the formal syntax > is not so helpful.) I put it in 5.3.8, and took it out of 7.2. A new draft will be out under separate cover. -- - Eric From owner-ietf-fax@imc.org Wed Mar 1 18:22:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16325 for ; Wed, 1 Mar 2000 18:22:30 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA09220 for ietf-fax-bks; Wed, 1 Mar 2000 13:30:49 -0800 (PST) Received: from mis2.centigram.com (pix78.centigram.com [198.137.183.78]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09216 for ; Wed, 1 Mar 2000 13:30:46 -0800 (PST) From: Eric.Burger@centigram.com Received: from notes.centigram.com (notes.centigram.com [129.1.11.64]) by mis2.centigram.com (8.9.1/8.9.1) with SMTP id NAA09008; Wed, 1 Mar 2000 13:30:17 -0800 (PST) Received: by notes.centigram.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 88256895.007632B2 ; Wed, 1 Mar 2000 13:31:02 -0800 X-Lotus-FromDomain: CENTIGRAM To: vpim@lists.neystadt.org, ietf-fax@imc.org, internet-drafts@ietf.org Message-ID: <88256895.007631CA.00@notes.centigram.com> Date: Wed, 1 Mar 2000 13:33:03 -0800 Subject: draft-ema-vpim-pndn-01.txt Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=fQNgHfMsDIV4VEzgaJr8sJbeHWkxCOBQ1dWv9uBWPAO1JagSZumUuuIC" Content-Disposition: inline Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --0__=fQNgHfMsDIV4VEzgaJr8sJbeHWkxCOBQ1dWv9uBWPAO1JagSZumUuuIC Content-type: text/plain; charset=us-ascii Content-Disposition: inline The new -01; this is different from the last -01, which was entered into the drafts' directory as -00. (See attached file: draft-ema-vpim-pndn-01.txt) --0__=fQNgHfMsDIV4VEzgaJr8sJbeHWkxCOBQ1dWv9uBWPAO1JagSZumUuuIC Content-type: application/octet-stream; name="draft-ema-vpim-pndn-01.txt" Content-Disposition: attachment; filename="draft-ema-vpim-pndn-01.txt" Content-Description: Text - character set unknown Content-Transfer-Encoding: x-uuencode begin 644 draft-ema-vpim-pndn-01.txt M#0H-"DYE='=O2!.;W1I9FEC871I;VX-"@T*#0I3=&%T=7,@;V8@ M=&AI`T*("`@;6]N=&AS+B`@3W1H97(@9&]C=6UE;G1S(&UA>2!U M<&1A=&4L(')E<&QA8V4L(&]R(&]B2!T:6UE+B`@270@:7,@:6YA<'!R;W!R:6%T92!T;R!U2!3=&%T=7,@3F]T:69I8V%T:6]N(&UE M8VAA;FES;2!D97-C7-T96TN("!4:&4@26YT97)N970@5F]I8V4@36%I;"!S>7-T96T@8V%N M(')E;F1E2US=&%T=7,@ M8V]N=&5N="UT>7!E("XN+BXN+BXN+BXV#0H@("`@(#4N,BX@(%!E7!E($9I96QD("XN+BXN+BXN M+BXN+BXN+BXN+BXN+BXN+BXQ,0T*("`@("`@("`U+C,N."X@(%-T871U"`M($5X86UP;&5S("XN+BXN+BXN+BXN M+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN,3(-"B`@("`@-BXQ+B`@ M4$Y$3B!7:71H($]N92!&86EL960@0F]D>2!087)T("XN+BXN+BXN+BXN+BXN M+BXN+BXN+BXN+BXN+C$S#0H@("`@(#8N,BX@(%!.1$X@5VET:"!4=V\@1F%I M;&5D($)O9'D@4&%R=',@+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXQ-`T* M("`@("`V+C,N("!03D1.(%=I=&@@3VYE($)O9'D@4&%R="!&86EL=7)E(&%N M9"!4=V\@4F5C:7!I96YT6YT87@@+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXN M+BXN+BXN+BXN+BXQ.`T*("`@."X@("!396-U2!#;VYS:61E7)I9VAT(%-T871E M;65N="`N+BXN+BXN+BXN+BXN+BXN+BXN+BXN+BXR,PT*#0H-"@T*#0HR+B`@ M($-O;G9E;G1I;VYS('5S960@:6X@=&AI2!T;R!T:&4@'!I2!W;W)D2!S:VEP('=I=&AO=70@;6ES2!B92!O9B!U2!N;W1I9FEC M871I;VYS(&%R92!A;B!E>'1E;G-I;VX@;V8@=&AE($1E;&EV97)Y#0H@("!3 M=&%T=7,@3F]T:69I8V%T:6]N("A$4TXI(&1E0T*("`@;65S7-T96T@2!B M=7-I;F5S2!V;VEC90T*("`@;65S`T*("`@96YA8FQE('1H92!V;VEC92!M86EL('-Y"!I;6%G97,@87,@=V5L;`T*("`@87,@8W)E M871E(&UU;'1I+7!A"!M97-S86=E'0M=&\M'0M=&\M9F%X#0H@("!T96-H;F]L;V=Y M+B`@06QT:&]U9V@@=&AE;W)E=&EC86QL>2!P;W-S:6)L92P@;F]N92!C86X@ M=&]D87D@2!O9B!T:&4@=F]I8V4@;65S2!.;W1I9FEC871I;VX@("`@("!-87)C:"`Q+"`R,#`P#0T*#0H-"B`@(')E M8VEP:65N="!C86X@96ET:&5R(&9I;F0@=&AE(&%P<')O<')I871E(')E;F1E M2!D969I;FET:6]N+"!A($U) M344M96YA8FQE9"!U7-T96T@;6%Y(&YO=`T*("`@8F4@8V%P86)L92!O9B!S=&]R M:6YG(&YO;BUV;VEC92!O8FIE8W1S+B`@36]R96]V97(L('1H92!V;VEC92!M M86EL#0H@("!S>7-T96T@;6%Y(&YO="!B92!C87!A8FQE(&]F(&YO=&EF>6EN M9R!T:&4@2!A('!E2X@($-O M;G1R87-T#0H@("!T:&ES('1O('1H92!C87-E('=I=&@@;F]R;6%L(&1A=&$@ M9&5L:79E2!O9B!A('-Y2!O8G-E7-T96T@9&ES8V]V97)S(&%N(&5R M2!P87)T+@T*#0H@("!4:&ES M(&1O8W5M96YT(&%D9')E2P@=&AE('9O:6-E(&UA:6P@2!T:&4@7-T96T@8V%N(&YO=&EF>0T* M("`@=&AE(')E8VEP:65N="!T:&5R92!W97)E('5N9&5L:79E2!P87)T7-T M96US(&%R90T*("`@;F]T(&-A<&%B;&4@;V8@;6%K:6YG('1H:7,@;F]T:69I M8V%T:6]N+@T*#0H@("!.3U1%.B!!;F]T:&5R(&UE=&AO9"!O9B!H86YD;&EN M9R!P87)T:6%L(&1E;&EV97)Y(&ES('1O(&1E=&5R;6EN90T*("`@=VAA="!P M87)T7-T96T@8V]U;&0@;F]T M(&1E;&EV97(@=&AE(&-R:71I8V%L('!A7-T96T@=V]U;&0@7-T96T@8V]U;&0@9&5L:79E M2!D96QE M=&4@=&AE('!A2!T:&5R92!I2!.;W1I9FEC871I;VX@("`@ M("!-87)C:"`Q+"`R,#`P#0T*#0H-"B`@($Y/5$4Z(%1H92!C;VYC97!T(&]F M(&$@8W)I=&EC86P@<&%R="!I;F1I8V%T;W(@:7,@2!A(&)O9'D@<&%R="!A2!P87)T6]N9"!T:&4@2!S M<&5C:6%L(&-O;G-I9&5R871I;VX@;VX@=&AE('!A2!E;F-O9&4@=&AE($U)344@ M;65S2!T;R!P2!P87)T(&]F('1H92!M M97-S86=E+"!I=`T*("`@=VEL;"!R971U2!N M;W1I9FEC871I;VX@2!F86EL=7)E(&-A;B!O M8V-U2UP87)T(&1E;&EV97)Y M(&9A:6QU"X@($YO=R!C;VYS:61E2!C;&%S2!3=&%T=7,@3F]T:69I8V%T:6]N("A$4TXI(%LS72!O=F5R($UE7-T96T@8V%N#0H@("!K;F]W(&]N(')E M8V5I<'0@=VAE=&AE2!H879E('-E;G0N#0H-"B`@(%1H92!03D1.(&ES(&$@7-T96T@=')A;G-M:71S(&$@4$Y$3B!A7!E(&]F(&UU M;'1I<&%R="]R97!O7-T96T@8V%N('5S92!T:&4@;75L=&EP87)T+W)E<&]R="!C;VYT M96YT+71Y<&4@9F]R(&%N>2!O9@T*("`@7!E('!A7!E M(&]F(")D96QI=F5R>2US=&%T=7,B+@T*#0H@("!!'!L86YA=&EO M;B!O9B!T:&4@7!E(&YA;64Z("`@("`@("`@("`@;65S2US M=&%T=7,-"B`@("`@3W!T:6]N86P@<&%R86UE=&5R2!.;W1I9FEC871I;VX@("`@("!-87)C:"`Q+"`R,#`P#0T*#0H-"B`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@8V]N9F]R;6EN9R!S>7-T96US M($U54U0@=7-E(&ET('1O#0H@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@(&UA:6YT86EN(')E861A8FEL:71Y('=H96X@=FEE=V5D#0H@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@(&)Y(&YO;BU-24U%(&UA:6P@2US=&%T=7,B M+@T*#0H@("!4:&4@8F]D>2!O9B!A(&UE7-T96US('=I;&P-"B`@(&=E;F5R871E(%!A2!.;W1I9FEC871I;VX@("`@("!-87)C:"`Q+"`R,#`P#0T*#0H- M"B`@('1H96ER(&UE2!O;B!A;'1E6EN9PT*("`@8VAA2UP87)T(&-O;G1E;G0@<&%R=&EA;"!N;VXM9&5L:79E2UP87)T+B`@02!B;&%N:PT*("`@;&EN M92!P'!A;F1S('5P;VX@1%-.(&)Y(&EN=')O9'5C:6YG(&)O9'D@ M<&%R="!I;F1I8V%T;W)S('1O($133B=S#0H@("!P97(M'1E;G-I;VX@86QL;W=S(&UU;'1I<&QE(')E8VEP:65N M=',@<&5R#0H@("!P97(M2!C:&]O2UP87)T("\@7,@;V8@2!. M;W1I9FEC871I;VX@("`@("!-87)C:"`Q+"`R,#`P#0T*#0H-"B`@("`@("`@ M("`@("!087)T(#$@1F%I;'5R90T*#0H@("`@("`@("`@("`@4F5C:7!I96YT M($(@1F%I;'5R90T*("`@("`@("`@("`@(%!A2!N;W1I9FEC871I;VXN#0H-"@T* M-2XS+C(N($%C=&EO;B!&:65L9`T*#0H@("!4:&4@86-T:6]N(&9I96QD(')E M9FQE8W1S('1H92!D:7-P;W-I=&EO;B!O9B!T:&4@;65S2!P87)T2!$4TX@ M6S-=+@T*#0H@("!.3U1%.B!#;VYS:61E'!E'!I2!R96%S;VYS+`T*("`@=&AE(%!. M1$X@7-T96T@:&ED9&5N('EE="!I;B!T M:&4-"B`@($EN=&5R;F5T(&YA;64@2!E M;F%B;&4@871T86-K2!P87)T('1H90T* M("`@2!P87)T#0H@ M("!T:&4@&%C=&QY M('=H:6-H(&)O9'D@<&%R="!T:&4@7!E(&9I96QD(&ES('!R97-E;G0@:6X@=&AE(&]R:6=I;F%L M(&UE&%C=&QY('=H:6-H(&)O9'D@<&%R="!T:&4-"B`@ M(')E8V5I=FEN9R!S>7-T96T@:7,@;F]T(&-A<&%B;&4@;V8@9&5L:79E7!E(#4N#0H-"B`@(%)E8V5I=FEN9R!S>7-T96US('1H870@ M9V5N97)A=&4@4&%R=&EA;"!.;VXM1&5L:79E2!H:7,@;65S7-T96T@:7,@;F]T(&-A<&%B;&4@;V8@9&5L:79E M7!E+"!I="!-55-4#0H@("!R M971U2!R96YD97(@=F]I8V4L('1H92!);G1E0T*("`@8V]N=F5R7-T M96T@4TA/54Q$($Y/5"!R971UF5D('1W;R!T:&EN9W,N#0H@("!&:7)S="P@9F5W($EN=&5R;F5T(%9O:6-E M($UA:6P@2!H879E('1H90T*#0I" M=7)G97(@("`@("`@("`@("!);G1E2!P87)T+"!S:&4@8V%N(&%L=V%Y M&%M<&QE2!A;F0@87)E(&YO=`T*("`@82!N;W)M871I=F4@<&%R="!O9B!T:&4@ M4$Y$3B!D969I;FET:6]N+B`@268@86X@97AA;7!L92!C;VYF;&EC=',-"B`@ M('=I=&@@=&AE(&YO"!U'1087)T7S`P,%\P,#`W7S`Q0D8S M-$4Q+C3H@,PT*("`@6"U-86EL97(Z M(%1H92!/;F4@06YD($]N;'D@5&5S="!0;&%T9F]R;2!6."XQ,C(R+CDW-$(- M"@T*("`@5&AI7!E.B!T97AT+W!L86EN.PT*("`@ M("`@("!C:&%R"X-"@T*#0H- M"B`@("TM+2TM+3U?3F5X=%!A'!I M7!E.B!A=61I;R]W M878[#0H@("`@("`@(&YA;64](E9O:6-E($UE6E48DEF1'EBDY92VUW0T=V5`T*("`@=T5R8DEG87I%=E)!1VXU:$UX:&-Q M1U,U.55%,6-(16I2,#A!#0H-"B`@("TM+2TM+3U?3F5X=%!A2!(;W5S90T*#0H@("!356MQ04)H4T%!04%!53)A9T%&3FUO04)46G%!054R M86=!1DYM;T%"5%IQ04%5,F%G049.;6]!0E1:<4%!53)A9T%&3@T*("`@054R M86=!1DYM;T%"5%IQ04%5,F%G049.;6]!0E1:<4%!53)A9T%'4G%$=4@T2F5F M53@O65-W9#@O>&1N-T-+0S1035<-"B`@("XN+@T*("`@54%!04=G149!045! M04%!255G04%'=T5&04%%04%!05%59T%!2D%%14%!14%!04%%04%!04M!141! M045!04%!0T%!04$-"B`@($%!04%!045!4F=%1$%!14%!04%!04%!05)W141! M045!04%!04%!04%!04%!04$]/0T*#0H@("`M+2TM+2T]7TYE>'1087)T7S`P M,%\P,#`W7S`Q0D8S-$4Q+C2!087)T#0H-"B`@(%1H:7,@97AA;7!L92!S M:&]W'0L#0H@("!B=70@9&]E"X-"@T* M#0H-"B`@($1A=&4Z(%1H=2P@,C(@3F]V(#$Y.3D@,#DZ,#4Z,34@+3`X,#`- M"B`@($9R;VTZ($UA:6P@1&5L:79E2!";V1Y(%!A7!E.B!M=6QT:7!A2US=&%T=7,[#0H@("`@("`@("!B;W5N9&%R>3TB4D%!,30Q,C@N M-S2!.;W1I9FEC871I;VX@ M("`@("!-87)C:"`Q+"`R,#`P#0T*#0H-"B`@(#QE2!P87)T('=I;&P@8F4@9&5L971E9"!F'0@;W(-"B`@(&9A>"X-"@T*#0H-"B`@($1A=&4Z(%1H=2P@ M,C(@3F]V(#$Y.3D@,#DZ,#4Z,34@+3`X,#`-"B`@($9R;VTZ($UA:6P@1&5L M:79E2!";V1Y(%!A7!E.B!M=6QT M:7!A2US=&%T=7,[#0H@ M("`@("`@("!B;W5N9&%R>3TB4D%!,30Q,C@N-S2!.;W1I9FEC871I;VX@("`@("!-87)C:"`Q+"`R,#`P M#0T*#0H-"B`@(#QE"!087)T('1O(#P@97)I8RYB=7)G97)`8V5N=&EG7!E.B!M97-S86=E+V1E;&EV97)Y+7-T871U2!(;W5S M92YT:68B#0H-"B`@("TM4D%!,30Q,C@N-S"X-"@T*("`@+2U204$Q-#$R."XW M-S,V,34W-C4O0T5.5$E'4D%-+D-/32TM#0H-"@T*#0HV+C,N(%!.1$X@5VET M:"!/;F4@0F]D>2!087)T($9A:6QU'0L#0H@("!B=70@9&]E"X@($%S2!";V1Y(%!A7!E/61E;&EV97)Y+7-T871U'0@4&%R="!T;R`\ M(&5R:6,N8G5R9V5R0&-E;G1I9W)A;2YC;VT@/@T*("`@0V]U;&0@3F]T($1E M;&EV97(@5&5X="!087)T('1O(#P@.#`P-34U,3(Q,D!V;2YS<"YN970@/@T* M#0H@("!";V1Y('!A7!E.B!M97-S86=E+V1E;&EV97)Y+7-T871U'!I2!";V1Y(%!A7!E.B!M M=6QT:7!A2US=&%T=7,[ M#0H@("`@("`@("!B;W5N9&%R>3TB4D%!,30Q,C@N-S'0@4&%R="!T;R`\ M(#@P,#4U-3$R,3)`=FTN"!087)T('1O(#P@97)I8RYB=7)G97)`8V5N=&EG'!I"X-"@T*("`@+2U204$Q-#$R."XW-S,V,34W-C4O0T5.5$E'4D%-+D-/ M32TM#0H-"@T*#0H-"C`T*#0H@("!4:&4@9F]L M;&]W:6YG('-Y;G1A>"!S<&5C:69I8V%T:6]N('5S97,@=&AE(&%U9VUE;G1E M9"!"86-K=7,M3F%U<@T*("`@1F]R;2`H0DY&*2!A2US=&%T=7,M8V]N=&5N M="`]#0H@("`@("`@("`@<&5R+6UE"!O9B!097(M365S'0-"@T*#0H@("!/"!O M9B!097(M4&%R="!&:65L9',-"@T*("`@<&5R+7!A2!.;W1I9FEC871I;VX@("`@("!-87)C:"`Q+"`R,#`P#0T* M#0H-"B`@("`@("!;(')E;6]T92UM=&$M9FEE;&0@0U),1B!=#0H@("`@("`@ M6R!D:6%G;F]S=&EC+6-O9&4M9FEE;&0@0U),1B!=#0H@("`@("`@6R!L87-T M+6%T=&5M<'0M9&%T92UF:65L9"!#4DQ&(%T-"B`@("`@("`J*"!E>'1E;G-I M;VXM9FEE;&0@0U),1B`I#0H-"@T*("`@86-T:6]N+69I96QD(#T-"B`@("`@ M("`@(D%C=&EO;CH@9&5L:79E'0-"@T*("`@;W)I9VEN86PM8V]N=&5N="UD:7-P;W-I=&EO;BUF M:65L9"`]#0H@("`@("`@("`@("`@(D]R:6=I;F%L+4-O;G1E;G0M1&ES<&]S M:71I;VXB("(Z(B!C;VYT96YT+61I7!E(#T@*G1E M>'0-"@T*("`@2!C;VYS:61E2!W:&5N('5S:6YG(%!.1$YS+@T*#0H-"@T*#0H-"D)U2!.;W1I9FEC871I;VX@("`@("!-87)C:"`Q+"`R M,#`P#0T*#0H-"C@N,2X@1F]R9V5R>0T*#0H@("!/;F4@8V%N(&9O&5S(BP-"B`@ M('-U8V@@87,@<&%G97)S+"!B96-O;64@;6]R92!W:61E;'D@=7-E9"!A2!A M;'-O(&%P<&QI97,@=&\@=&AE('-E7-T M96T@=&\@871T86-K+@T*#0H@("!-5$$@875T:&]R2!O<'1I;VYA;"!03D1.(&9I M96QD#0H@("!T:&%T(&ET(&1E=&5R;6EN97,@:6YC;'5S:6]N(&]F('1H92!F M:65L9"!W;W5L9"!I;7!O0T*("`@=7-E9"P@4F5T=7)N+5)E8V5I<'0M5&\@97AT96YS:6]N(&AE M861E2!3=&%T=7,@3F]T:69I8V%T M:6]N7!E(&9O2`Q.3DV+@T*#0H@("`Q,"!#6YT87@-"B`@ M("`@(%-P96-I9FEC871I;VYS.B!!0DY&(BP@4D9#(#(R,S0L($EN=&5R;F5T M($UA:6P@0V]N2`Q.3DV+@T* M#0H-"@T*#0HQ,"X@("`@06-K;F]W;&5D9VUE;G1S#0H-"B`@($DG9"!L:6ME M('1O('1H86YK($=R86AA;2!+;'EN92!A;F0@2V5I=&@@36]O6YE(&%L2!O=VX-"B`@(&9A=6QT+@T*#0H@("!.960@1G)E960@ M86YD($AE'!E M'!I7)I9VAT(%-T871E;65N=`T*#0H@("!4:&4@24541B!T86ME0T* M("`@:6YT96QL96-T=6%L('!R;W!E2!D97-C2!S=6-H(')I9VAT2!R:6=H M=',@8GD@:6UP;&5M96YT;W)S(&]R('5S97)S(&]F('1H:7,@2!T:&%T(&UA>2!B92!R97%U:7)E9"!T;R!P&5C=71I=F4-"B`@($1I2!B92!P2!N;W0@8F4@;6]D:69I960@:6X@ M86YY('=A>2P@2!R96UO=FEN9PT*("`@=&AE(&-O<'ER:6=H M="!N;W1I8V4@;W(@2!OF%T:6]N7)I9VAT.2\Q+S(P,#`@("`@("`@("`@6U!A9V4@,C-=#0H, ` end --0__=fQNgHfMsDIV4VEzgaJr8sJbeHWkxCOBQ1dWv9uBWPAO1JagSZumUuuIC-- From owner-ietf-fax@imc.org Thu Mar 2 07:55:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11237 for ; Thu, 2 Mar 2000 07:55:05 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA16725 for ietf-fax-bks; Thu, 2 Mar 2000 04:05:59 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA16716 for ; Thu, 2 Mar 2000 04:05:56 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10304; Thu, 2 Mar 2000 07:06:01 -0500 (EST) Message-Id: <200003021206.HAA10304@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-fax@imc.org From: The IESG Subject: Protocol Action: GSTN address element extensions in e-mail services to Proposed Standard Date: Thu, 02 Mar 2000 07:06:01 -0500 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'GSTN address element extensions in e-mail services' as a Proposed Standard. This document is the product of the Internet Fax Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom. Technical Summary This document defines a comprehensive syntax for incorporating E.164 telephone addresses on the Left Hand Side of electronic mail addresses. This syntax includes all of the elements previously defined within the standards track document RFC 2303 "Minimal PSTN address format in Internet Mail", plus additional elements that were not included within that document. This document also includes the necesssary IANA considerations so that current and future phone address elements can be properly registered after review within the IETF. This document has been under review in the WG and in other communities interested in telephony address elements during the past year. The document is believed to be stable and complete. In addition to its use in Internet FAX this address syntax is expected to be useful in the Voice Profile for Internet Mail (VPIM) work, and this work has been reviewed by a VPIM mailing list. It is also aligned with the tel: and fax: URLs recently approved for Proposed Standard status. Working Group Summary This document has benefitted from extensive review both within the FAX group and within other groups of interest. Protocol Quality Keith Moore reviewed the spec for IESG, and believes it is technically sound. Note to RFC Editor: Please be aware of the typo in section 1.1 1.1 Relathiship with Internet addressing other than e-mail ^^^^^^^^^^^ Relationship From owner-ietf-fax@imc.org Thu Mar 2 22:11:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04639 for ; Thu, 2 Mar 2000 22:11:19 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA05688 for ietf-fax-bks; Thu, 2 Mar 2000 18:05:34 -0800 (PST) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA05681 for ; Thu, 2 Mar 2000 18:05:33 -0800 (PST) Received: from laptop.ix.netcom.com (pool-209-138-4-98.ipls.grid.net [209.138.4.98]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id VAA18349; Thu, 2 Mar 2000 21:05:05 -0500 (EST) Message-Id: <4.3.2.20000302174117.00b682a0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 02 Mar 2000 17:44:02 -0600 To: ifx@pwg.org, ipp@pwg.org, ietf-fax@imc.org From: Richard Shockey Subject: QUALDOCS MEETING TIME IN AUSTRALIA Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For those of you who are interested I just received word that we do have space in Australia. QUALDOCS is scheduled for Tuesday at 1300-1400. If you have any additional agenda items let me know. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From owner-ietf-fax@mail.imc.org Mon Mar 6 11:57:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14576 for ; Mon, 6 Mar 2000 11:57:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA01910 for ietf-fax-bks; Mon, 6 Mar 2000 08:24:32 -0800 (PST) Received: from Brooktrout.Com (truite.brooktrout.com [204.176.74.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01902 for ; Mon, 6 Mar 2000 08:24:31 -0800 (PST) Received: from nhmail1.admin.brooktrout.com (nhmail1.admin.brooktrout.com [204.176.75.8]) by Brooktrout.Com (8.9.3/8.9.3/BTI-2.1) with ESMTP id LAA25807; Mon, 6 Mar 2000 11:15:31 -0500 Message-Id: <200003061615.LAA25807@Brooktrout.Com> Received: from jraff.brooktrout.com (dhcp24.sales.brooktrout.com [204.176.75.171]) by nhmail1.admin.brooktrout.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1W13DF1A; Mon, 6 Mar 2000 11:18:00 -0500 X-Sender: jrafferty@humancomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 06 Mar 2000 10:01:04 -0500 To: Ietf-Fax From: James Rafferty Subject: Fwd: Protocol Action: GSTN address element extensions in e-mail services to Proposed Standard Cc: "VPIM discussion list" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To all - My congratulations to Claudio Allocchio and the rest of the Fax WG for approval of the full addressing draft. I'm also copying the VPIM WG, since they have also indicated a desire to use the resulting approach for defining GSTN elements within email addresses. James >To: IETF-Announce: ; >Cc: RFC Editor >Cc: Internet Architecture Board >Cc: ietf-fax@imc.org >From: The IESG >Subject: Protocol Action: GSTN address element extensions in e-mail > services to Proposed Standard >Date: Thu, 02 Mar 2000 07:06:01 -0500 >Sender: owner-ietf-fax@imc.org >List-Archive: >List-ID: >List-Unsubscribe: > > > >The IESG has approved the Internet-Draft 'GSTN address element >extensions in e-mail services' as a >Proposed Standard. This document is the product of the Internet Fax >Working Group. The IESG contact persons are Keith Moore and Patrik >Faltstrom. > > >Technical Summary > >This document defines a comprehensive syntax for incorporating E.164 >telephone addresses on the Left Hand Side of electronic mail addresses. >This syntax includes all of the elements previously defined within the >standards track document RFC 2303 "Minimal PSTN address format in Internet >Mail", plus additional elements that were not included within that >document. This document also includes the necesssary IANA considerations >so that current and future phone address elements can be properly >registered after review within the IETF. > >This document has been under review in the WG and in other communities >interested in telephony address elements during the past year. The >document is believed to be stable and complete. > >In addition to its use in Internet FAX this address syntax is expected >to be useful in the Voice Profile for Internet Mail (VPIM) work, and >this work has been reviewed by a VPIM mailing list. > >It is also aligned with the tel: and fax: URLs recently approved >for Proposed Standard status. > >Working Group Summary > >This document has benefitted from extensive review both within the >FAX group and within other groups of interest. > >Protocol Quality > >Keith Moore reviewed the spec for IESG, and believes it is technically >sound. > > >Note to RFC Editor: > >Please be aware of the typo in section 1.1 > >1.1 Relathiship with Internet addressing other than e-mail > ^^^^^^^^^^^ Relationship > From owner-ietf-fax@mail.imc.org Mon Mar 6 17:24:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14519 for ; Mon, 6 Mar 2000 17:24:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA07816 for ietf-fax-bks; Mon, 6 Mar 2000 13:55:37 -0800 (PST) Received: from Brooktrout.Com (truite.brooktrout.com [204.176.74.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA07811 for ; Mon, 6 Mar 2000 13:55:35 -0800 (PST) Received: from nhmail1.admin.brooktrout.com (nhmail1.admin.brooktrout.com [204.176.75.8]) by Brooktrout.Com (8.9.3/8.9.3/BTI-2.1) with ESMTP id QAA26971; Mon, 6 Mar 2000 16:40:09 -0500 Received: from jraff.brooktrout.com (dhcp24.sales.brooktrout.com [204.176.75.171]) by nhmail1.admin.brooktrout.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1W13DGFW; Mon, 6 Mar 2000 16:42:39 -0500 Message-Id: X-Sender: jrafferty@humancomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 06 Mar 2000 16:42:14 -0500 To: Ietf-Fax From: James Rafferty Subject: Appointment of new Internet Fax Co-Chairs Cc: Claudio Allocchio +39 40 3758523 , "H. Tamura" , Keith Moore , Ned Freed , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Herman R. Silbiger" , TSG8IFAX Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, I am pleased to announce that ADs have agreed to a new co-chair team to manage the Internet Fax efforts going forward. The co-chairs will be: Hiroshi Tamura and Claudio Allocchio Tamura-san is very well known in the fax standards community and has been an important contributor to the work of the IETF and the ITU in recent years. Claudio has been active in the IETF and the email community for many years and been a contributor to drafts for the Internet Fax WG from our earliest days. He is also the author of RFC 2303-2304, as well as the recently approved Full Addressing specification. We are fortunate to have a team with this kind of extensive experience to guide new Internet Fax work going forward. Please join me in welcoming Claudio and Tamura-san in their new roles. I will continue to be available to help in the transition of WG management to the new team, but my current job responsibilities have less involvement with Internet fax via email. Going forward, the best contact email address for me will be . We are still working out with the ADs whether the resulting work will be done as a re-charter to the existing WG or as an Internet Fax Extensions WG. In either course, the basis for the work will be the draft charter which was recently circulated to this list. We also expect to continue the excellent pattern of cooperation with the ITU fax experts going forward. Best Regards, James Rafferty (outgoing) Chair, Internet Fax WG From owner-ietf-fax@mail.imc.org Mon Mar 6 20:37:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21380 for ; Mon, 6 Mar 2000 20:37:00 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA10919 for ietf-fax-bks; Mon, 6 Mar 2000 17:06:29 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA10915 for ; Mon, 6 Mar 2000 17:06:26 -0800 (PST) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id KAA02758; Tue, 7 Mar 2000 10:06:32 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id KAA05961; Tue, 7 Mar 2000 10:06:30 +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 KAA00238; Tue, 7 Mar 2000 10:02:21 +0900 (JST) To: moore+iesg@cs.utk.edu, paf@swip.net, Ned.Freed@innosoft.com Cc: Claudio.Allocchio@elettra.trieste.it, ietf-fax@imc.org Subject: [Fax] Charter(fixed) X-Mailer: Mew version 1.94.1 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Mar_07_10:09:50_2000_444)--" Content-Transfer-Encoding: 7bit Message-Id: <20000307101009U.tamura@toda.ricoh.co.jp> Date: Tue, 07 Mar 2000 10:10:09 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 128 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----Next_Part(Tue_Mar_07_10:09:50_2000_444)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attached is the charter of FaxExt wg. Please review it. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) ----Next_Part(Tue_Mar_07_10:09:50_2000_444)-- Content-Type: Text/Plain; charset=us-ascii Content-Disposition: attachment; filename="FaxExt_charter.txt" Content-Transfer-Encoding: 7bit Internet Fax Extensions (faxext) -------------------------------- Chair(s): Hiroshi Tamura Claudio Allocchio Applications Area Director(s): Keith Moore Patrik Faltstrom Area Advisor ? Mailing lists: General Discussion:ietf-fax@imc.org To Subscribe: ietf-fax-request@imc.org In Body: In Body: subscribe Archive: http://www.imc.org/ietf-fax/ DESCRIPTION OF WORKING GROUP: Previous IETF efforts developed specifications for simple and extended Internet mail-based facsimile service profiles, tailored to interwork with the world of T.30 facsimile. This extension effort will produce a final increment of specification for supporting a "full" equivalence of T.30 service over Internet mail. Technical work for this effort includes timely delivery, [image] feature selection/negotiation, document privacy, and integrated specification of Full-mode Facsimile Profile of Internet Mail (FFPIM). Differential routing between classic Internet mail and timely deliveries will be considered, as will universal messaging issues. For interconnecting fax services over the dial-up telephone network and carriage of facsimile message data over the Internet, two types of interface systems are required: o Internet/Dial-up Fax gateway, moving data from the Internet to classic or Internet-aware dial-up fax products and services o Dial-up/Internet Fax gateway, moving data from classic or Internet-aware dial-up fax products and services to the Internet The working group will also consider the requirements for gatewaying Internet Mail (as profiled for facsimile Simple, Extended modes and FFPIM) with T.30 Facsimile. The working group will specifically take note of quality of service issues and might decide to produce an Implementer's Guide. T.30 facsimile carries expectations of message privacy, so that FFPIM must specify a basic facility via the Internet. Although T.30 does not provide document authentication, users frequently believe that it does. Consequently the Faxext working group will also seek specification of a basic authentication facility over the Internet. T.30 facsimile provides for receiver capability identification to the sender, allowing a sender to provide the "best" fax image the receiver can handle. The Faxext working group will consider mechanisms to provide similar functionality for fax images transferred by e-mail. Additional areas of discussion will be: Annotated fax messages and universal messaging issues as they relate to FFPIM, as well as schema and TIFF extensions required to support the new JBIG-2 (T.88) compression method. The working group will continue the excellent pattern of coordinating activities with other facsimile-related standards bodies, in particular the ITU, and with using work from related IETF efforts. GOALS AND MILESTONES: Mar 2000 Working Group chartered Mar 2000 Initial draft for timely delivery Mar 2000 Initial draft for content negotiaton for fax Mar 2000 Initial draft for FFPIM Mar 2000 Initial draft of Implementors Guide for Simple and Extended mode Jun 2000 Revised draft for timely delivery Jun 2000 Revised draft for content negotiaton for fax Jun 2000 Revised draft for FFPIM Jul 2000 Initial draft of Routing considerations Jul 2000 Initial draft of gateway requirements Jul 2000 Final draft of Implementors Guide for Simple and Extended mode Sep 2000 Initial drafts of schema and TIFF-fx extensions for JBIG-2 Nov 2000 Final draft for timely delivery Nov 2000 Final draft for content negotiaton for fax Nov 2000 Final draft of FFPIM Nov 2000 Final draft of Routing Considerations Mar 2001 Final draft of gateway requirements Apr 2001 Final drafts of schema and TIFF-fx extensions for JBIG-2 ----Next_Part(Tue_Mar_07_10:09:50_2000_444)---- From owner-ietf-fax@mail.imc.org Tue Mar 7 05:44:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20504 for ; Tue, 7 Mar 2000 05:44:09 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA07517 for ietf-fax-bks; Tue, 7 Mar 2000 02:16:27 -0800 (PST) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA07508 for ; Tue, 7 Mar 2000 02:16:09 -0800 (PST) Date: Tue, 7 Mar 2000 11:15:55 +0100 To: James Rafferty cc: Ietf-Fax , "H. Tamura" , Keith Moore , Ned Freed , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Herman R. Silbiger" , TSG8IFAX In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Re: Appointment of new Internet Fax Co-Chairs Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > We are fortunate to have a team with this kind of extensive experience to > guide new Internet Fax work going forward. > Please join me in welcoming Claudio and Tamura-san in their new roles. Thank you James ! I hope Tamura-san and myself can continue the very good job you and Dave did in this complex flield which involves different communities sharing the common interest of global messaging service! In order to do this we will need the WG support, but I'm sure that we will have the same very collabortive spirit around, and we will make it! > done as a re-charter to the existing WG or > as an Internet Fax Extensions WG. In either course, the basis for the > work will be the draft charter which was recently circulated to this list. > We also expect to continue the excellent pattern of cooperation with the > ITU fax experts going forward. So do we ! Regards to everybody! Claudio Allocchio PS: as some of you already did, please send us the requests for time slots in the Adelaide meeting, and any other suggestion/hint you may have. From owner-ietf-fax@mail.imc.org Tue Mar 7 06:07:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24842 for ; Tue, 7 Mar 2000 06:07:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA08189 for ietf-fax-bks; Tue, 7 Mar 2000 02:46:05 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08185 for ; Tue, 7 Mar 2000 02:46:03 -0800 (PST) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id TAA21550; Tue, 7 Mar 2000 19:46:35 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id TAA24051; Tue, 7 Mar 2000 19:46:34 +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 TAA00294; Tue, 7 Mar 2000 19:42:25 +0900 (JST) To: jrafferty@humancomm.com Cc: ietf-fax@imc.org, Claudio.Allocchio@elettra.trieste.it, moore@cs.utk.edu, Ned.Freed@innosoft.com, paf@swip.net, hsilbiger@hiway1.exit109.com, tsg8ifax@ITU.CH Subject: Re: Appointment of new Internet Fax Co-Chairs In-Reply-To: References: X-Mailer: Mew version 1.94.1 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: <20000307195015A.tamura@toda.ricoh.co.jp> Date: Tue, 07 Mar 2000 19:50:15 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 12 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rafferty-san, Thank you for your notification and clarfication. I hope Allocchio-san and I can continue the jobs related to this group, with the support of many people here. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@mail.imc.org Tue Mar 7 14:38:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15730 for ; Tue, 7 Mar 2000 14:38:11 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20561 for ietf-fax-bks; Tue, 7 Mar 2000 11:06:51 -0800 (PST) Received: from Brooktrout.Com (truite.brooktrout.com [204.176.74.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20557 for ; Tue, 7 Mar 2000 11:06:50 -0800 (PST) Received: from nhmail1.admin.brooktrout.com (nhmail1.admin.brooktrout.com [204.176.75.8]) by Brooktrout.Com (8.9.3/8.9.3/BTI-2.1) with ESMTP id NAA29439; Tue, 7 Mar 2000 13:40:22 -0500 Received: by nhmail1.admin.brooktrout.com with Internet Mail Service (5.5.2448.0) id <1W13D2NS>; Tue, 7 Mar 2000 13:43:00 -0500 Message-ID: <11740AB18BD4D111BE8F00A0C9B8044F0227EE93@nhmail1.admin.brooktrout.com> From: James Rafferty To: "'Internet Drafts'" Cc: "'Glenn Parsons'" , "'Steve Zilles'" , "'IETF Fax List'" , "'Claudio Allocchio'" , "'H. Tamura'" Subject: draft-ietf-fax-tiff-regbis-00.txt Date: Tue, 7 Mar 2000 13:42:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please add this document to the Internet Drafts Archives. The document is a revision to RFC 2302 and is a product of the IETF Internet Fax working group. I am the outgoing chair of this WG. I have also cced the new chairs (Hiroshi Tamura and Claudio Allocchio) on the request, in case you want concurrence from one of them. James * ----------------------------------- James Rafferty Senior Product Manager, IP Telephony Brooktrout Technology 410 First Avenue Needham, MA 02494 USA Phone: +1-781-433-9462 Fax: 781-433-9268 Email/Internet Fax: jraff@brooktrout.com Alt Email: jrafferty@worldnet.att.net From owner-ietf-fax@mail.imc.org Tue Mar 7 15:01:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23215 for ; Tue, 7 Mar 2000 15:01:35 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA20556 for ietf-fax-bks; Tue, 7 Mar 2000 11:06:49 -0800 (PST) Received: from Brooktrout.Com (truite.brooktrout.com [204.176.74.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20551 for ; Tue, 7 Mar 2000 11:06:47 -0800 (PST) Received: from nhmail1.admin.brooktrout.com (nhmail1.admin.brooktrout.com [204.176.75.8]) by Brooktrout.Com (8.9.3/8.9.3/BTI-2.1) with ESMTP id NAA29480; Tue, 7 Mar 2000 13:52:34 -0500 Received: by nhmail1.admin.brooktrout.com with Internet Mail Service (5.5.2448.0) id <1W13D237>; Tue, 7 Mar 2000 13:55:12 -0500 Message-ID: <11740AB18BD4D111BE8F00A0C9B8044F0227EE94@nhmail1.admin.brooktrout.com> From: James Rafferty To: "'Internet Drafts'" Cc: "'Glenn Parsons'" , "'Steve Zilles'" , "'IETF Fax List'" , "'Claudio Allocchio'" , "'H. Tamura'" Subject: RE: draft-ietf-fax-tiff-regbis-00.txt (resend with attachment) Date: Tue, 7 Mar 2000 13:55:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF8866.AAD6C2CA" 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_000_01BF8866.AAD6C2CA Content-Type: text/plain; charset="iso-8859-1" This version has the attachment. James > -----Original Message----- > From: James Rafferty > Sent: Tuesday, March 07, 2000 1:43 PM > To: 'Internet Drafts' > Cc: 'Glenn Parsons'; 'Steve Zilles'; 'IETF Fax List'; 'Claudio > Allocchio'; 'H. Tamura' > Subject: draft-ietf-fax-tiff-regbis-00.txt (resend with attachment) > > > Please add this document to the Internet Drafts Archives. > > The document is a revision to RFC 2302 and is a product of > the IETF Internet Fax working group. > > I am the outgoing chair of this WG. I have also cced the new > chairs (Hiroshi Tamura and Claudio Allocchio) on the request, > in case you want concurrence from one of them. > > James > > > > * ----------------------------------- > James Rafferty > Senior Product Manager, IP Telephony > Brooktrout Technology > 410 First Avenue > Needham, MA 02494 USA > > Phone: +1-781-433-9462 > Fax: 781-433-9268 > Email/Internet Fax: jraff@brooktrout.com > Alt Email: jrafferty@worldnet.att.net > ------_=_NextPart_000_01BF8866.AAD6C2CA Content-Type: text/plain; name="draft-ietf-fax-tiff-regbis-00.txt" Content-Disposition: attachment; filename="draft-ietf-fax-tiff-regbis-00.txt" Content-Transfer-Encoding: quoted-printable Network Working Group G. = Parsons Internet Draft Nortel = Networks J. = Rafferty Brooktrout = Technology Document: S. = Zilles Category: Informational Adobe Systems, = Inc. March 6, = 2000 =20 =20 Tag Image File Format (TIFF) - image/tiff=20 MIME Sub-type Registration=20 =20 =20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance=20 with all provisions of Section 10 of RFC2026 except that the=20 right to produce derivative works is not granted. =20 =20 Internet-Drafts are working documents of the Internet=20 Engineering Task Force (IETF), its areas, and its working=20 groups. Note that other groups may also distribute working=20 documents as Internet-Drafts.=20 =20 Internet Drafts are valid for a maximum of six months and may=20 be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet Drafts as=20 reference material or to cite them other than as a "work in=20 progress".=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 =20 The list of Internet-Draft Shadow Directories can be accessed=20 at http://www.ietf.org/shadow.html.=20 =20 =20 1. Abstract=20 =20 =20 This document describes the registration of the MIME sub-type=20 image/tiff. The baseline encoding is defined by [TIFF]. =20 This document refines an earlier sub-type registration in RFC=20 1528 [TPC.INT].=20 =20 =20 =20 =20 =20 =20 =20 =20 =0C Internet Draft image/tiff March 6, = 2000=20 =20 2. Conventions used in this document=20 =20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL=20 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and=20 "OPTIONAL" in this document are to be interpreted as=20 described in RFC-2119 [REQ].=20 =20 =20 3. Overview=20 =20 =20 This document describes the registration of the MIME sub-type=20 image/tiff. The baseline encoding is defined by [TIFF].=20 =20 =20 4. Internet Fax Working Group=20 =20 =20 This document is a product of the IETF Internet Fax Working=20 Group. All comments on this document should be forwarded to=20 the email distribution list at .=20 =20 =20 5. TIFF Definition=20 =20 =20 TIFF (Tag Image File Format) Revision 6.0 is defined in=20 detail by Adobe in [TIFF]. The documentation can be obtained=20 from Adobe at:=20 =20 Adobe Developers Association=20 Adobe Systems Incorporated=20 345 Park Avenue=20 San Jose, CA 95110-2704=20 =20 Phone: +1-408-536-6000=20 Fax: +1-408-537-6000=20 =20 A copy of this specification can also be found in:=20 ftp://ftp.adobe.com/pub/adobe/devrelations/devtechnotes/pdffi les/tiff6.pdf=20 =20 While a brief scope and feature description is provided in=20 this section as background information, the reader is=20 directed to the original TIFF specification [TIFF] to obtain=20 complete feature and technical details.=20 =20 =20 =20 =20 =20 =20 =0C Internet Draft image/tiff March 6, = 2000=20 =20 5.1 TIFF Scope=20 =20 =20 TIFF describes image data that typically comes from scanners,=20 frame grabbers, and paint- and photo-retouching programs.=20 TIFF is not a printer language or page description language.=20 The purpose of TIFF is to describe and store raster image=20 data. A primary goal of TIFF is to provide a rich =20 environment within which applications can exchange image=20 data. This richness is required to take advantage of the=20 varying capabilities of scanners and other imaging devices. =20 Though TIFF is a rich format, it can easily be used for=20 simple scanners and applications as well because the number=20 of required fields is small.=20 =20 =20 5.2 TIFF Features=20 =20 =20 Some of the features of TIFF (from [TIFF]) are:=20 =20 - TIFF is capable of describing bilevel, grayscale, palette- color, and full-color image data in several color spaces.=20 =20 - TIFF includes a number of compression schemes that allow=20 developers to choose the best space or time tradeoff for=20 their applications.=20 =20 - TIFF is designed to be extensible and to evolve gracefully=20 as new needs arise.=20 =20 - TIFF allows the inclusion of an unlimited amount of private=20 or special-purpose information.=20 =20 =20 6. MIME Definition=20 =20 =20 6.1 image/tiff=20 =20 =20 The image/tiff content-type was previously defined in RFC1528=20 as containing TIFF 6.0 encoded image data, with specific=20 reference made to a subset known as TIFF Class F. This=20 document redefines the original image/tiff definition to=20 refer to TIFF 6.0 [TIFF] encoded image data, consistent with=20 existing practice for TIFF aware Internet applications. This=20 definition is further enhanced by introducing the new=20 "application parameter" (section 6.2) to enable=20 identification of a specific subset of TIFF and TIFF=20 extensions for the encoded image data.=20 =20 =20 =20 =0C Internet Draft image/tiff March 6, = 2000=20 =20 6.2 Application parameter=20 =20 =20 There are cases where it may be useful to identify the=20 application applicable to the content of an image/tiff body.=20 Typically, this would be used to assist the recipient in=20 dispatching a suitable rendering package to handle the=20 display or processing of the image file. As a result, an=20 optional "application" parameter is defined for image/tiff to=20 identify a particular application's subset of TIFF and TIFF=20 extensions for the encoded image data, if it is known. No=20 values are defined in this document. =20 =20 Example:=20 =20 Content-type: image/tiff; application=3Dfoo=20 =20 There is no default value for application, as the absence of=20 the application parameter indicates that the encoded TIFF=20 image is Baseline TIFF or that it is not necessary to=20 identify the application. It is up to the recipient's=20 implementation to determine the application (if necessary)=20 and render the image to the user. =20 =20 =20 7. IANA Registration=20 =20 =20 To: ietf-types@iana.org=20 Subject: Registration of Standard MIME media type =20 image/tiff=20 =20 MIME media type name: image=20 =20 MIME subtype name: tiff=20 =20 Required parameters: none=20 =20 Optional parameters: application=20 =20 There is no format specified for the value of this=20 parameter in addition to that specified by [MIME1]. =20 Various applications of TIFF may define values as=20 required. There is no default value for application,=20 as the absence of the application parameter indicates=20 that the encoded TIFF image is Baseline TIFF or that=20 it is not necessary to identify the application. It=20 is up to the implementation to determine the=20 application (if necessary) and render the image to=20 the user.=20 =20 =20 =20 =20 =0C Internet Draft image/tiff March 6, = 2000=20 =20 Encoding considerations: =20 =20 Binary or Base-64 generally preferred=20 =20 Security considerations: =20 =20 TIFF utilizes a structure which can store image data and=20 attributes of this image data. The fields defined in the=20 TIFF specification are of a descriptive nature and provide = information that is useful to facilitate viewing and=20 rendering of images by a recipient. As such, the fields=20 currently defined in the TIFF specification do not in=20 themselves create additional security risks, since the=20 fields are not used to induce any particular behavior by=20 the recipient application.=20 =20 TIFF has an extensible structure, so that it is=20 theoretically possible that fields could be defined=20 in the future which could be used to induce=20 particular actions on the part of the recipient, thus=20 presenting additional security risks, but this type=20 of capability is not supported in the referenced TIFF=20 specification. Indeed, the definition of fields which=20 would include such processing instructions is=20 inconsistent with the goals and spirit of the TIFF=20 specification.=20 =20 Interoperability considerations: =20 =20 The ability of implementations to handle all the=20 defined applications (or profiles within=20 applications) of TIFF may not be ubiquitous. As a=20 result, implementations may decode and attempt to=20 display the encoded TIFF image data only to determine=20 that the image cannot be rendered. The presence of=20 the application parameter may aid in allowing this=20 determination before dispatching for rendering. =20 However, it should be noted that the parameter value=20 is not intended to convey levels of capabilities for=20 a particular application.=20 =20 Published specification:=20 =20 TIFF (Tag Image File Format) is defined in:=20 TIFF (TM) Revision 6.0 - Final _ June 3, 1992=20 =20 Adobe Developers Association=20 Adobe Systems Incorporated=20 345 Park Avenue=20 San Jose, CA 95110-2704=20 =20 Phone: +1-408-536-6000=20 Fax: +1-408-537-6000=20 =20 =0C Internet Draft image/tiff March 6, = 2000=20 =20 A copy of this specification can be found in:=20 ftp://ftp.adobe.com/pub/adobe/devrelations/devtechnotes/pd ffiles/tiff6.pdf=20 =20 Applications which use this media type: =20 =20 Imaging, fax, messaging and multi-media=20 =20 Additional information:=20 =20 Magic number(s): =20 II (little-endian): 49 49 42 00 hex=20 MM (big-endian): 4D 4D 00 42 hex=20 File extension(s): .TIF=20 Macintosh File Type Code(s): TIFF=20 =20 Person & email address to contact for further information:=20 =20 Glenn W. Parsons=20 gparsons@nortelnetworks.com =20 =20 James Rafferty=20 jraff@brooktrout.com=20 =20 Stephen Zilles=20 szilles@adobe.com=20 =20 Intended usage: COMMON=20 =20 Change controller: Stephen Zilles=20 =20 =20 8. References=20 =20 =20 [REQ] Bradner, S., "Key words for use in RFCs to Indicate =20 Requirement Levels", BCP 14, RFC 2119, March 1997.=20 =20 [MIME1] N. Freed and N. Borenstein, "Multipurpose Internet =20 Mail Extensions (MIME) Part One: Format of Internet =20 Message Bodies", RFC 2045, Innosoft, First Virtual, Nov =20 1996=20 =20 [MIME4] N. Freed and N. Borenstein, "Multipurpose Internet =20 Mail Extensions (MIME) Part Four: Registration=20 Procedures", RFC 2048, Innosoft, First Virtual, Nov=20 1996.=20 =20 [TIFF] Adobe Developers Association, TIFF (TM) Revision 6.0 - =20 Final, June 3, 1992.=20 =20 =20 =20 =20 =0C Internet Draft image/tiff March 6, = 2000=20 =20 [TPC.INT] C. Malamud, M. Rose, "Principles of Operation for =20 the TPC.INT Subdomain: Remote Printing -- Technical=20 Procedures", RFC 1528, 10/06/1993=20 =20 =20 9. Author's Addresses=20 =20 =20 Glenn W. Parsons=20 Nortel Networks=20 P.O. Box 3511, Station C=20 Ottawa, ON K1Y 4H7=20 Canada=20 Phone: +1-613-763-7582=20 Fax: +1-613-763-2697=20 Email: gparsons@nortelnetworks.com=20 =20 James Rafferty=20 Brooktrout Technology=20 410 First Avenue=20 Needham, MA 02494=20 USA=20 Phone: +1-781-433-9462=20 Fax: +1-781-433-9268=20 Email: jraff@brooktrout.com=20 =20 Stephen Zilles=20 Adobe Systems Inc.=20 Mailstop W14=20 345 Park Avenue=20 San Jose, CA 95110-2704=20 USA=20 Voice: +1-408-536-4766=20 Fax: +1-408-536-4042=20 Email: szilles@adobe.com=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =0C Internet Draft image/tiff March 6, = 2000=20 Appendix A: IANA Registration form for new values of Application=20 Parameter=20 To: IANA@isi.edu =20 =20 Subject: Registration of new values for the Application parameter = of image/tiff=20 =20 MIME type name: image/tiff=20 =20 Optional Parameter: Application=20 =20 New Value(s): Application=3Dfoo=20 =20 Description of Use:=20 =20 foo - (Ofoo0 is a fictional new value used in this message as =20 an example, it is to be replaced with the new value being=20 registered. Include a short description of the use of the=20 new value here. This must include reference to a standards=20 track RFC for the complete description; the use of the=20 value must be defined completely enough for independent=20 implementation.)=20 =20 Security Considerations:=20 =20 (Any additional security considerations that may be introduced=20 by useof the new parameter should be defined here or in the=20 referenced standards track RFC.)=20 =20 Person & email address to contact for further information:=20 =20 Glenn W. Parsons=20 gparsons@nortelnetworks.com =20 =20 James Rafferty=20 jraff@brooktrout.com=20 =20 Stephen Zilles=20 szilles@adobe.com =20 =20 INFORMATION TO THE SUBMITTER:=20 The accepted registrations will be listed in the "Assigned=20 Numbers" series of RFCs. The information in the registration=20 form is freely distributable.=20 =20 =20 =20 =20 =20 =20 =20 =20 =0C Internet Draft image/tiff March 6, = 2000=20 =20 Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2000). All Rights=20 Reserved.=20 =20 This document and translations of it may be copied and=20 furnished to others, and derivative works that comment on or=20 otherwise explain it or assist in its implementation may be=20 prepared, copied, published and distributed, in whole or in=20 part, without restriction of any kind, provided that the=20 above copyright notice and this paragraph are included on all=20 such copies and derivative works. However, this document=20 itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or=20 other Internet organizations, except as needed for the=20 purpose of developing Internet standards in which case the=20 procedures for copyrights defined in the Internet Standards=20 process must be followed, or as required to translate it into=20 languages other than English.=20 =20 The limited permissions granted above are perpetual and will=20 not be revoked by the Internet Society or its successors or=20 assigns.=20 =20 This document and the information contained herein is provided=20 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET=20 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR=20 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE=20 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR=20 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A=20 PARTICULAR PURPOSE.=20 =20 =0C ------_=_NextPart_000_01BF8866.AAD6C2CA-- From owner-ietf-fax@mail.imc.org Tue Mar 7 15:27:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02147 for ; Tue, 7 Mar 2000 15:27:11 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA21134 for ietf-fax-bks; Tue, 7 Mar 2000 11:39:11 -0800 (PST) Received: from pasiphae.eastgw.xerox.com (root@pasiphae.xerox.com [208.140.33.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21126 for ; Tue, 7 Mar 2000 11:39:08 -0800 (PST) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by pasiphae.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id OAA20876; Tue, 7 Mar 2000 14:39:12 -0500 (EST) 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 LAA01640; Tue, 7 Mar 2000 11:39:10 -0800 (PST) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2448.0) id ; Tue, 7 Mar 2000 11:39:11 -0800 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A2770@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'James Rafferty'" , "'Internet Drafts'" Cc: "'Glenn Parsons'" , "'Steve Zilles'" , "'IETF Fax List'" , "'Claudio Allocchio'" , "'H. Tamura'" Subject: RE: draft-ietf-fax-tiff-regbis-00.txt (resend with attachment) Date: Tue, 7 Mar 2000 11:39:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF886C.CEBEBB80" 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_000_01BF886C.CEBEBB80 Content-Type: text/plain; charset="iso-8859-1" James, I am surprised that you sent the draft version rather than the issued RFC version, which is attached. Lloyd > -----Original Message----- > From: James Rafferty [mailto:jraff@needham.BROOKTROUT.com] > Sent: Tuesday, March 07, 2000 10:55 AM > To: 'Internet Drafts' > Cc: 'Glenn Parsons'; 'Steve Zilles'; 'IETF Fax List'; 'Claudio > Allocchio'; 'H. Tamura' > Subject: RE: draft-ietf-fax-tiff-regbis-00.txt (resend with > attachment) > > > This version has the attachment. > > James > > > -----Original Message----- > > From: James Rafferty > > Sent: Tuesday, March 07, 2000 1:43 PM > > To: 'Internet Drafts' > > Cc: 'Glenn Parsons'; 'Steve Zilles'; 'IETF Fax List'; 'Claudio > > Allocchio'; 'H. Tamura' > > Subject: draft-ietf-fax-tiff-regbis-00.txt (resend with attachment) > > > > > > Please add this document to the Internet Drafts Archives. > > > > The document is a revision to RFC 2302 and is a product of > > the IETF Internet Fax working group. > > > > I am the outgoing chair of this WG. I have also cced the new > > chairs (Hiroshi Tamura and Claudio Allocchio) on the request, > > in case you want concurrence from one of them. > > > > James > > > > > > > > * ----------------------------------- > > James Rafferty > > Senior Product Manager, IP Telephony > > Brooktrout Technology > > 410 First Avenue > > Needham, MA 02494 USA > > > > Phone: +1-781-433-9462 > > Fax: 781-433-9268 > > Email/Internet Fax: jraff@brooktrout.com > > Alt Email: jrafferty@worldnet.att.net > > > > ------_=_NextPart_000_01BF886C.CEBEBB80 Content-Type: text/plain; name="rfc2302_image-tiff_registration.txt" Content-Disposition: attachment; filename="rfc2302_image-tiff_registration.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Network Working Group G. = Parsons=0A= Request for Comments: 2302 Northern = Telecom=0A= Category: Standards Track J. = Rafferty=0A= Human = Communications=0A= S. = Zilles=0A= Adobe Systems, = Inc.=0A= March 1998=0A= =0A= =0A= Tag Image File Format (TIFF) - image/tiff=0A= MIME Sub-type Registration=0A= =0A= =0A= Status of this Memo=0A= =0A= This document specifies an Internet standards track protocol for = the=0A= Internet community, and requests discussion and suggestions for=0A= improvements. Please refer to the current edition of the = "Internet=0A= Official Protocol Standards" (STD 1) for the standardization = state=0A= and status of this protocol. Distribution of this memo is = unlimited.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (1998). All Rights Reserved.=0A= =0A= Overview=0A= =0A= This document describes the registration of the MIME sub-type=0A= image/tiff. The baseline encoding is defined by [TIFF].=0A= =0A= Internet Fax Working Group=0A= =0A= This document is a product of the IETF Internet Fax Working = Group.=0A= All comments on this document should be forwarded to the email=0A= distribution list at .=0A= =0A= 1. Abstract=0A= =0A= This document describes the registration of the MIME sub-type=0A= image/tiff. The baseline encoding is defined by [TIFF]. This=0A= document refines an earlier sub-type registration in RFC 1528=0A= [TPC.INT].=0A= =0A= 2. TIFF Definition=0A= =0A= TIFF (Tag Image File Format) Revision 6.0 is defined in detail by=0A= Adobe in [TIFF]. The documentation can be obtained from Adobe = at:=0A= =0A= =0A= =0A= =0A= Parsons, et. al. Standards Track [Page = 1]=0A= =0C=0A= RFC 2302 TIFF March = 1998=0A= =0A= =0A= Adobe Developers Association=0A= Adobe Systems Incorporated=0A= 345 Park Avenue=0A= San Jose, CA 95110-2704=0A= =0A= Phone: +1-408-536-6000=0A= Fax: +1-408-537-6000=0A= =0A= A copy of this specification can also be found in:=0A= ftp://ftp.adobe.com/pub/adobe/devrelations/devtechnotes/pdffiles/=0A= tiff6.pdf=0A= =0A= While a brief scope and feature description is provided in this=0A= section as background information, the reader is directed to the=0A= original TIFF specification [TIFF] to obtain complete feature and=0A= technical details.=0A= =0A= 2.1 TIFF Scope=0A= =0A= TIFF describes image data that typically comes from scanners, = frame=0A= grabbers, and paint- and photo-retouching programs. TIFF is not a=0A= printer language or page description language. The purpose of TIFF = is=0A= to describe and store raster image data. A primary goal of TIFF = is=0A= to provide a rich environment within which applications can = exchange=0A= image data. This richness is required to take advantage of the=0A= varying capabilities of scanners and other imaging devices. = Though=0A= TIFF is a rich format, it can easily be used for simple scanners = and=0A= applications as well because the number of required fields is = small.=0A= =0A= 2.2 TIFF Features=0A= =0A= Some of the features of TIFF (from [TIFF]) are:=0A= =0A= - TIFF is capable of describing bilevel, grayscale, = palette-color,=0A= and full-color image data in several color spaces.=0A= =0A= - TIFF includes a number of compression schemes that allow=0A= developers to choose the best space or time tradeoff for their=0A= applications.=0A= =0A= - TIFF is designed to be extensible and to evolve gracefully as = new=0A= needs arise.=0A= =0A= - TIFF allows the inclusion of an unlimited amount of private or=0A= special-purpose information.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Parsons, et. al. Standards Track [Page = 2]=0A= =0C=0A= RFC 2302 TIFF March = 1998=0A= =0A= =0A= 3. MIME Definition=0A= =0A= 3.1 image/tiff=0A= =0A= The image/tiff content-type was previously defined in RFC 1528 as=0A= containing TIFF 6.0 encoded image data, with specific reference = made=0A= to a subset known as TIFF Class F. This document re-defines the=0A= original image/tiff definition to refer to all of the profiles = and=0A= extensions that build on TIFF 6.0 [TIFF] encoded image data,=0A= consistent with existing practice for TIFF aware Internet=0A= applications. This definition is further enhanced by introducing = the=0A= new "application parameter" (section 3.2) to enable identification = of=0A= a specific subset of TIFF and TIFF extensions for the encoded = image=0A= data.=0A= =0A= 3.2 Application parameter=0A= =0A= There are cases where it may be useful to identify the = application=0A= applicable to the content of an image/tiff body. Typically, this=0A= would be used to assist the recipient in dispatching a suitable=0A= rendering package to handle the display or processing of the = image=0A= file. As a result, an optional "application" parameter is = defined=0A= for image/tiff to identify a particular application's subset of = TIFF=0A= and TIFF extensions for the encoded image data, if it is known. = No=0A= values are defined in this document.=0A= =0A= Example using a fictional value 'foo':=0A= =0A= Content-type: image/tiff; application=3Dfoo=0A= =0A= There is no default value for application, as the absence of the=0A= application parameter indicates that the encoded TIFF image is=0A= Baseline TIFF or that it is not necessary to identify the=0A= application. It is up to the recipient's implementation to=0A= determine the application (if necessary) and render the image to = the=0A= user.=0A= =0A= 4. IANA Registration=0A= =0A= To: ietf-types@iana.org=0A= Subject: Registration of Standard MIME media type image/tiff=0A= =0A= MIME media type name: image=0A= =0A= MIME subtype name: tiff=0A= =0A= Required parameters: none=0A= =0A= =0A= =0A= =0A= Parsons, et. al. Standards Track [Page = 3]=0A= =0C=0A= RFC 2302 TIFF March = 1998=0A= =0A= =0A= Optional parameters: application=0A= =0A= There is no format specified for the value of this parameter=0A= in addition to that specified by [MIME1]. Various=0A= applications of TIFF may define values as required. New=0A= values should be defined in standards track RFCs and the=0A= values should be registered with IANA, using the=0A= registration form included in Appendix A. There is no=0A= default value for application, as the absence of the=0A= application parameter indicates that the encoded TIFF image=0A= is Baseline TIFF or that it is not necessary to identify the=0A= application. It is up to the implementation to determine=0A= the application (if necessary) and render the image to the=0A= user.=0A= =0A= Encoding considerations: Binary or Base-64 generally preferred=0A= =0A= Security considerations:=0A= =0A= TIFF utilizes a structure which can store image data and=0A= attributes of this image data. The fields defined in the=0A= TIFF specification are of a descriptive nature and provide=0A= information that is useful to facilitate viewing and=0A= rendering of images by a recipient. As such, the fields=0A= currently defined in the TIFF specification do not in=0A= themselves create additional security risks, since the=0A= fields are not used to induce any particular behavior by=0A= the recipient application.=0A= =0A= TIFF has an extensible structure, so that it is=0A= theoretically possible that fields could be defined in the=0A= future which could be used to induce particular actions on=0A= the part of the recipient, thus presenting additional=0A= security risks, but this type of capability is not=0A= supported in the referenced TIFF specification. Indeed, the=0A= definition of fields which would include such processing=0A= instructions is inconsistent with the goals and spirit of=0A= the TIFF specification.=0A= =0A= Interoperability considerations:=0A= =0A= The ability of implementations to handle all the defined=0A= applications (or profiles within applications) of TIFF may=0A= not be ubiquitous. As a result, implementations may decode=0A= and attempt to display the encoded TIFF image data only to=0A= determine that the image cannot be rendered. The presence=0A= of the application parameter may aid in allowing this=0A= determination before dispatching for rendering. However, it=0A= =0A= =0A= =0A= Parsons, et. al. Standards Track [Page = 4]=0A= =0C=0A= RFC 2302 TIFF March = 1998=0A= =0A= =0A= should be noted that the parameter value is not intended to=0A= convey levels of capabilities for a particular application.=0A= =0A= Published specification:=0A= =0A= TIFF (Tag Image File Format) is defined in:=0A= TIFF (TM) Revision 6.0 - Final - June 3, 1992=0A= =0A= Adobe Developers Association=0A= Adobe Systems Incorporated=0A= 345 Park Avenue=0A= San Jose, CA 95110-2704=0A= =0A= Phone: +1-408-536-6000=0A= Fax: +1-408-537-6000=0A= =0A= A copy of this specification can be found in:=0A= ftp://ftp.adobe.com/pub/adobe/devrelations/devtechnotes/pdff=0A= iles/tiff6.pdf=0A= =0A= Applications which use this media type:=0A= =0A= Imaging, fax, messaging and multi-media=0A= =0A= Additional information:=0A= =0A= Magic number(s):=0A= II (little-endian): 49 49 42 00 hex=0A= MM (big-endian): 4D 4D 00 42 hex=0A= File extension(s): .TIF=0A= Macintosh File Type Code(s): TIFF=0A= =0A= Person & email address to contact for further information:=0A= =0A= Glenn W. Parsons=0A= Glenn.Parsons@Nortel.ca=0A= =0A= James Rafferty=0A= Jrafferty@worldnet.att.net=0A= =0A= Stephen Zilles=0A= szilles@adobe.com=0A= =0A= Intended usage: COMMON=0A= =0A= Change controller: Stephen Zilles=0A= =0A= =0A= =0A= =0A= =0A= Parsons, et. al. Standards Track [Page = 5]=0A= =0C=0A= RFC 2302 TIFF March = 1998=0A= =0A= =0A= 5. Authors' Addresses=0A= =0A= Glenn W. Parsons=0A= Northern Telecom=0A= P.O. Box 3511, Station C=0A= Ottawa, ON K1Y 4H7=0A= Canada=0A= Phone: +1-613-763-7582=0A= Fax: +1-613-763-2697=0A= Email: Glenn.Parsons@Nortel.ca=0A= =0A= James Rafferty=0A= Human Communications=0A= 12 Kevin Drive=0A= Danbury, CT 06811-2901=0A= USA=0A= Phone: +1-203-746-4367=0A= Fax: +1-203-746-4367=0A= Email: Jrafferty@worldnet.att.net=0A= =0A= Stephen Zilles=0A= Adobe Systems Inc.=0A= Mailstop W14=0A= 345 Park Avenue=0A= San Jose, CA 95110-2704=0A= USA=0A= Voice: +1-408-536-4766=0A= Fax: +1-408-536-4042=0A= Email: szilles@adobe.com=0A= =0A= 6. References=0A= =0A= [MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet = Mail=0A= Extensions (MIME) Part One: Format of Internet Message = Bodies",=0A= RFC 2045, November 1996.=0A= [MIME4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail=0A= Extensions (MIME) Part Four: Registration Procedures", RFC = 2048,=0A= November 1996.=0A= [TIFF] Adobe Developers Association, TIFF (TM) Revision 6.0 - = Final,=0A= June 3, 1992.=0A= [TPC.INT] Malamud, C. and M. Rose, "Principles of Operation for = the=0A= TPC.INT Subdomain: Remote Printing -- Technical = Procedures",=0A= RFC 1528, October 1993.=0A= [TIFFPLUS] McIntyre, L., Zilles, S., Buckley, R., Venable, D.,=0A= Parsons, G., and J. Rafferty, "File Format for Internet = Fax",=0A= RFC 2301, March 1998.=0A= [TIFF] Parsons, G., and J. Rafferty, "Tag Image File Format=0A= TIFF) -- R Profile for Facsimile, RFC 2306, March 1998.=0A= =0A= =0A= =0A= Parsons, et. al. Standards Track [Page = 6]=0A= =0C=0A= RFC 2302 TIFF March = 1998=0A= =0A= =0A= Appendix A: IANA Registration form for new values of Application=0A= Parameter=0A= =0A= To: IANA@isi.edu Subject: Registration of new values for the=0A= Application parameter=0A= of image/tiff=0A= =0A= MIME type name:=0A= =0A= image/tiff=0A= =0A= Optional Parameter:=0A= =0A= Application=0A= =0A= New Value(s):=0A= =0A= Application=3Dfoo=0A= =0A= Description of Use:=0A= =0A= foo - (=D5foo=D8 is a fictional new value used in this message as = an=0A= example, it is to be replaced with the new value being=0A= registered. Include a short description of the use of = the=0A= new value here. This must include reference to a = standards=0A= track RFC for the complete description; the use of the=0A= value must be defined completely enough for independent=0A= implementation. )=0A= =0A= Security Considerations:=0A= =0A= (Any additional security considerations that may be introduced by = use=0A= of the new parameter should be defined here or in the referenced=0A= standards track RFC.)=0A= =0A= Person & email address to contact for further information:=0A= =0A= (fill in contact information)=0A= =0A= INFORMATION TO THE SUBMITTER:=0A= =0A= The accepted registrations will be listed in the "Assigned = Numbers"=0A= series of RFCs. The information in the registration form is = freely=0A= distributable.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Parsons, et. al. Standards Track [Page = 7]=0A= =0C=0A= RFC 2302 TIFF March = 1998=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (1998). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished = to=0A= others, and derivative works that comment on or otherwise explain = it=0A= or assist in its implementation may be prepared, copied, = published=0A= and distributed, in whole or in part, without restriction of any=0A= kind, provided that the above copyright notice and this paragraph = are=0A= included on all such copies and derivative works. However, this=0A= document itself may not be modified in any way, such as by = removing=0A= the copyright notice or references to the Internet Society or = other=0A= Internet organizations, except as needed for the purpose of=0A= developing Internet standards in which case the procedures for=0A= copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other = than=0A= English.=0A= =0A= The limited permissions granted above are perpetual and will not = be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on = an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, = INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Parsons, et. al. Standards Track [Page = 8]=0A= =0C=0A= ------_=_NextPart_000_01BF886C.CEBEBB80-- From owner-ietf-fax@mail.imc.org Tue Mar 7 16:12:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15002 for ; Tue, 7 Mar 2000 16:12:38 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA22118 for ietf-fax-bks; Tue, 7 Mar 2000 12:39:48 -0800 (PST) Received: from Brooktrout.Com (truite.brooktrout.com [204.176.74.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22113 for ; Tue, 7 Mar 2000 12:39:43 -0800 (PST) Received: from nhmail1.admin.brooktrout.com (nhmail1.admin.brooktrout.com [204.176.75.8]) by Brooktrout.Com (8.9.3/8.9.3/BTI-2.1) with ESMTP id PAA29796; Tue, 7 Mar 2000 15:25:55 -0500 Received: by nhmail1.admin.brooktrout.com with Internet Mail Service (5.5.2448.0) id <1W13D25M>; Tue, 7 Mar 2000 15:28:34 -0500 Message-ID: <11740AB18BD4D111BE8F00A0C9B8044F0227EE95@nhmail1.admin.brooktrout.com> From: James Rafferty To: "'McIntyre, Lloyd'" , "'Internet Drafts'" Cc: "'Glenn Parsons'" , "'Steve Zilles'" , "'IETF Fax List'" , "'Claudio Allocchio'" , "'H. Tamura'" Subject: RE: draft-ietf-fax-tiff-regbis-00.txt (resend with attachment) Date: Tue, 7 Mar 2000 15:28:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lloyd, The contact information has changed. Hence, the ID needs to be submitted to reflect this. There are no other changes. This is being submitted as part of the process needed in order to be able to submit the most recent TIFF-FX ID for draft std consideration. James > -----Original Message----- > From: McIntyre, Lloyd [mailto:Lloyd.McIntyre@pahv.xerox.com] > Sent: Tuesday, March 07, 2000 2:39 PM > To: 'James Rafferty'; 'Internet Drafts' > Cc: 'Glenn Parsons'; 'Steve Zilles'; 'IETF Fax List'; 'Claudio > Allocchio'; 'H. Tamura' > Subject: RE: draft-ietf-fax-tiff-regbis-00.txt (resend with > attachment) > > > > James, > I am surprised that you sent the draft version rather than > the issued RFC > version, which is attached. > > Lloyd > > > -----Original Message----- > > From: James Rafferty [mailto:jraff@needham.BROOKTROUT.com] > > Sent: Tuesday, March 07, 2000 10:55 AM > > To: 'Internet Drafts' > > Cc: 'Glenn Parsons'; 'Steve Zilles'; 'IETF Fax List'; 'Claudio > > Allocchio'; 'H. Tamura' > > Subject: RE: draft-ietf-fax-tiff-regbis-00.txt (resend with > > attachment) > > > > > > This version has the attachment. > > > > James > > > > > -----Original Message----- > > > From: James Rafferty > > > Sent: Tuesday, March 07, 2000 1:43 PM > > > To: 'Internet Drafts' > > > Cc: 'Glenn Parsons'; 'Steve Zilles'; 'IETF Fax List'; 'Claudio > > > Allocchio'; 'H. Tamura' > > > Subject: draft-ietf-fax-tiff-regbis-00.txt (resend with > attachment) > > > > > > > > > Please add this document to the Internet Drafts Archives. > > > > > > The document is a revision to RFC 2302 and is a product of > > > the IETF Internet Fax working group. > > > > > > I am the outgoing chair of this WG. I have also cced the new > > > chairs (Hiroshi Tamura and Claudio Allocchio) on the request, > > > in case you want concurrence from one of them. > > > > > > James > > > > > > > > > > > > * ----------------------------------- > > > James Rafferty > > > Senior Product Manager, IP Telephony > > > Brooktrout Technology > > > 410 First Avenue > > > Needham, MA 02494 USA > > > > > > Phone: +1-781-433-9462 > > > Fax: 781-433-9268 > > > Email/Internet Fax: jraff@brooktrout.com > > > Alt Email: jrafferty@worldnet.att.net > > > > > > > > > From owner-ietf-fax@mail.imc.org Tue Mar 7 17:03:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29855 for ; Tue, 7 Mar 2000 17:03:12 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA22950 for ietf-fax-bks; Tue, 7 Mar 2000 13:40:12 -0800 (PST) Received: from mailgw2.netvision.net.il (mailgw2.netvision.net.il [194.90.1.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22945 for ; Tue, 7 Mar 2000 13:40:09 -0800 (PST) Received: from sendout.icomverse.com (Efrat-FR3.ser.netvision.net.il [199.203.174.65]) by mailgw2.netvision.net.il (8.9.3/8.9.3) with ESMTP id XAA29523; Tue, 7 Mar 2000 23:40:43 +0200 (IST) Received: from unity-mail.icomverse.com (unity-mail.icomverse.com [89.119.41.3]) by sendout.icomverse.com (8.9.3/8.8.7) with ESMTP id XAA21259; Tue, 7 Mar 2000 23:41:11 +0200 Received: by unity-mail.icomverse.com with Internet Mail Service (5.5.2650.21) id <10G20X4R>; Tue, 7 Mar 2000 23:38:51 +0200 Message-ID: <5B34AF33D291D311A06D0004AC1509D7C374B9@unity-mail.icomverse.com> From: "Neystadt, John" To: "'Larry Masinter'" , ned.freed@innosoft.com Cc: IETF VPIM List , ietf-fax@imc.org Subject: RE: [VPIM] Analogy to Content-Duration for Faxes Date: Tue, 7 Mar 2000 23:38:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ua-media doesn't fits well, we are not talking about user agents here. I think registering media feaure "pages" is a better one. What should be done to go forward with this. It seems to small item for an RFC, can't we take tremp and add it into draft-ietf-conneg-content-features.txt? John Neystadt john@neystadt.org http://www.neystadt.org/john/ > -----Original Message----- > From: Larry Masinter [mailto:LM@att.com] > Sent: Thu, February 10, 2000 4:35 AM > To: ned.freed@innosoft.com > Cc: Neystadt, John; IETF VPIM List; ietf-fax@imc.org > Subject: RE: [VPIM] Analogy to Content-Duration for Faxes > > > > # > Content-Features: pages=10 > > # > to note a 10-page document. > > # Might even want to have an additional attribute to say what > sort of "page" > # you're talking about. > > RFC 2534 already registers 'ua-media' tag with values such as > 'screen-paged' > and 'stationery' (most likely the kind of pages you'd want > with faxes), and > a 'paper-size' tag with additional token values. At the time > RFC 2534 was > written, we were focusing mainly on media features for > recipients rather > than > for content; you might still want to characterize a fax > recipient as having > a maximum number of pages its willing to receive, though. > > > > From owner-ietf-fax@mail.imc.org Wed Mar 8 06:33:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29262 for ; Wed, 8 Mar 2000 06:33:17 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA00298 for ietf-fax-bks; Wed, 8 Mar 2000 03:01:14 -0800 (PST) Received: from monsoon.mail.pipex.net (monsoon.mail.pipex.net [158.43.128.69]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA00288 for ; Wed, 8 Mar 2000 03:01:12 -0800 (PST) Received: (qmail 10405 invoked from network); 8 Mar 2000 11:01:51 -0000 Received: from userfa25.uk.uudial.com (HELO GK-VAIO) (62.188.19.195) by smtp.dial.pipex.com with SMTP; 8 Mar 2000 11:01:51 -0000 Message-Id: <4.2.2.20000308103632.00c35710@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 08 Mar 2000 10:44:36 +0000 To: "Neystadt, John" From: Graham Klyne Subject: RE: [VPIM] Analogy to Content-Duration for Faxes Cc: conneg WG , IETF VPIM List , ietf-fax@imc.org In-Reply-To: <5B34AF33D291D311A06D0004AC1509D7C374B9@unity-mail.icomvers e.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John, I think there's nothing wrong with a small RFC :-) has already gone forward for last call, and the IESG review is (at least) partially done. Also, there's not an obvious linkage between registration of "pages" and the "content-features:" header proposal, so I think they are better kept separate. BTW, I think Larry's proposal was always to register "pages", as you suggest, and that the reference to "UA-media" was simply a (subsidiary) possibility to qualify the kind of "page" being indicated. Regards, #g -- At 11:38 PM 3/7/00 +0200, Neystadt, John wrote: >ua-media doesn't fits well, we are not talking about user agents here. > >I think registering media feaure "pages" is a better one. > >What should be done to go forward with this. It seems to small item for an >RFC, can't we take tremp and add it into >draft-ietf-conneg-content-features.txt? > >John Neystadt >john@neystadt.org >http://www.neystadt.org/john/ > > > > > -----Original Message----- > > From: Larry Masinter [mailto:LM@att.com] > > Sent: Thu, February 10, 2000 4:35 AM > > To: ned.freed@innosoft.com > > Cc: Neystadt, John; IETF VPIM List; ietf-fax@imc.org > > Subject: RE: [VPIM] Analogy to Content-Duration for Faxes > > > > > > > > # > Content-Features: pages=10 > > > > # > to note a 10-page document. > > > > # Might even want to have an additional attribute to say what > > sort of "page" > > # you're talking about. > > > > RFC 2534 already registers 'ua-media' tag with values such as > > 'screen-paged' > > and 'stationery' (most likely the kind of pages you'd want > > with faxes), and > > a 'paper-size' tag with additional token values. At the time > > RFC 2534 was > > written, we were focusing mainly on media features for > > recipients rather > > than > > for content; you might still want to characterize a fax > > recipient as having > > a maximum number of pages its willing to receive, though. > > > > > > > > ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Wed Mar 8 06:45:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02962 for ; Wed, 8 Mar 2000 06:45:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA04222 for ietf-fax-bks; Wed, 8 Mar 2000 03:19:13 -0800 (PST) Received: from elettra.trieste.it (SYNW10.elettra.trieste.it [140.105.2.12]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA04216 for ; Wed, 8 Mar 2000 03:19:10 -0800 (PST) Date: Wed, 8 Mar 2000 12:18:33 +0100 To: Hiroshi Tamura cc: moore+iesg@cs.utk.edu, paf@swip.net, Ned.Freed@innosoft.com, ietf-fax@imc.org In-Reply-To: <20000307101009U.tamura@toda.ricoh.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Re: [Fax] Charter(fixed) Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallo, just on possible suggestion to the charter: I'd add the explicit reference to the cooperation with the VPIM group where we talk about global unified messaging service. regards, Claudio From owner-ietf-fax@mail.imc.org Wed Mar 8 06:54:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05380 for ; Wed, 8 Mar 2000 06:54:39 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA04842 for ietf-fax-bks; Wed, 8 Mar 2000 03:31:58 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA04836 for ; Wed, 8 Mar 2000 03:31:56 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29013; Wed, 8 Mar 2000 06:32:35 -0500 (EST) Message-Id: <200003081132.GAA29013@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-tiff-regbis-00.txt Date: Wed, 08 Mar 2000 06:32:34 -0500 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 : Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration Author(s) : G. Parsons, J. Rafferty, S. Zilles Filename : draft-ietf-fax-tiff-regbis-00.txt Pages : 9 Date : 07-Mar-00 This document describes the registration of the MIME sub-type image/tiff. The baseline encoding is defined by [TIFF]. This document refines an earlier sub-type registration in RFC 1528 [TPC.INT]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-tiff-regbis-00.txt 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-tiff-regbis-00.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-tiff-regbis-00.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: <20000307141323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-tiff-regbis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-tiff-regbis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000307141323.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Wed Mar 8 07:02:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07800 for ; Wed, 8 Mar 2000 07:02:06 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA04931 for ietf-fax-bks; Wed, 8 Mar 2000 03:32:56 -0800 (PST) Received: from mailgw2.netvision.net.il (mailgw2.netvision.net.il [194.90.1.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA04924; Wed, 8 Mar 2000 03:32:54 -0800 (PST) Received: from sendout.icomverse.com (Efrat-FR3.ser.netvision.net.il [199.203.174.65]) by mailgw2.netvision.net.il (8.9.3/8.9.3) with ESMTP id NAA27723; Wed, 8 Mar 2000 13:33:33 +0200 (IST) Received: from unity-mail.icomverse.com (unity-mail.icomverse.com [89.119.41.3]) by sendout.icomverse.com (8.9.3/8.8.7) with ESMTP id NAA30878; Wed, 8 Mar 2000 13:34:00 +0200 Received: by unity-mail.icomverse.com with Internet Mail Service (5.5.2650.21) id <10G20X7Z>; Wed, 8 Mar 2000 13:31:40 +0200 Message-ID: <5B34AF33D291D311A06D0004AC1509D7C374C6@unity-mail.icomverse.com> From: "Neystadt, John" To: IETF VPIM List , ietf-fax@imc.org Cc: conneg WG Subject: RE: [VPIM] Analogy to Content-Duration for Faxes Date: Wed, 8 Mar 2000 13:31:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: So, what should be a way to advance with this, should I try to write a draft for this feature? John Neystadt john@neystadt.org http://www.neystadt.org/john/ > -----Original Message----- > From: Graham Klyne [mailto:GK@Dial.pipex.com] > Sent: Wed, March 08, 2000 12:45 PM > To: Neystadt, John > Cc: conneg WG; IETF VPIM List; ietf-fax@imc.org > Subject: RE: [VPIM] Analogy to Content-Duration for Faxes > > > John, > > I think there's nothing wrong with a small RFC :-) > > has already gone > forward for > last call, and the IESG review is (at least) partially done. > Also, there's > not an obvious linkage between registration of "pages" and the > "content-features:" header proposal, so I think they are > better kept separate. > > BTW, I think Larry's proposal was always to register "pages", as you > suggest, and that the reference to "UA-media" was simply a > (subsidiary) > possibility to qualify the kind of "page" being indicated. > > Regards, > > #g > -- > > > At 11:38 PM 3/7/00 +0200, Neystadt, John wrote: > >ua-media doesn't fits well, we are not talking about user > agents here. > > > >I think registering media feaure "pages" is a better one. > > > >What should be done to go forward with this. It seems to > small item for an > >RFC, can't we take tremp and add it into > >draft-ietf-conneg-content-features.txt? > > > >John Neystadt > >john@neystadt.org > >http://www.neystadt.org/john/ > > > > > > > > > -----Original Message----- > > > From: Larry Masinter [mailto:LM@att.com] > > > Sent: Thu, February 10, 2000 4:35 AM > > > To: ned.freed@innosoft.com > > > Cc: Neystadt, John; IETF VPIM List; ietf-fax@imc.org > > > Subject: RE: [VPIM] Analogy to Content-Duration for Faxes > > > > > > > > > > > > # > Content-Features: pages=10 > > > > > > # > to note a 10-page document. > > > > > > # Might even want to have an additional attribute to say what > > > sort of "page" > > > # you're talking about. > > > > > > RFC 2534 already registers 'ua-media' tag with values such as > > > 'screen-paged' > > > and 'stationery' (most likely the kind of pages you'd want > > > with faxes), and > > > a 'paper-size' tag with additional token values. At the time > > > RFC 2534 was > > > written, we were focusing mainly on media features for > > > recipients rather > > > than > > > for content; you might still want to characterize a fax > > > recipient as having > > > a maximum number of pages its willing to receive, though. > > > > > > > > > > > > > > ------------ > Graham Klyne > (GK@ACM.ORG) > > From owner-ietf-fax@mail.imc.org Wed Mar 8 10:05:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11215 for ; Wed, 8 Mar 2000 10:05:46 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA12307 for ietf-fax-bks; Wed, 8 Mar 2000 06:32:52 -0800 (PST) Received: from Brooktrout.Com (truite.brooktrout.com [204.176.74.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12302 for ; Wed, 8 Mar 2000 06:32:51 -0800 (PST) Received: from nhmail1.admin.brooktrout.com (nhmail1.admin.brooktrout.com [204.176.75.8]) by Brooktrout.Com (8.9.3/8.9.3/BTI-2.1) with ESMTP id JAA31656; Wed, 8 Mar 2000 09:21:41 -0500 Received: by nhmail1.admin.brooktrout.com with Internet Mail Service (5.5.2448.0) id <1W13DKQL>; Wed, 8 Mar 2000 09:24:26 -0500 Message-ID: <11740AB18BD4D111BE8F00A0C9B8044F0227EE97@nhmail1.admin.brooktrout.com> From: James Rafferty To: "'IETF Fax List'" Cc: "'Keith Moore'" , "'Ned Freed'" , =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , "'H. Tamura'" , "'Claudio Allocchio'" Subject: [Fax] WG Last Call Report on Progressing Simple Mode Documents Date: Wed, 8 Mar 2000 09:24:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, Late in November, we had a WG Last Call on the "Simple Mode" documents which have been under consideration for the status of Draft Standard. This note is a report on the results of that WG Last Call. It has been delayed in part in the hope that some of the outstanding issues could be resolved, but various issues are still open as indicated below. The purpose of the last call was for a final review of the collection of drafts which have updated the Simple Mode documents which are currently RFC 2301, RFC 2303-4 and RFC 2305. RFC 2302 was also considered to be among the documents proposed for progression to draft standard. Per the IETF process, the requirements to progress to draft standard entail a review of the documents based on implementor experience and preparation of documentation on interworking demonstrating that there are at least 2 independent implementations that use all of the features and are able to interwork. A third requirement is that all normative references contained in the documents to progress must also be at the draft standard or higher level. During the WG Last Call period in November and December, no additional technical comments were made. This is not surprising since the documents had been under review for several months. However, some small editorial changes were identified for some of the documents, basically just to provide some small editorial corrections and update contact information where needed. The results of the WG Last Call are as follows: The document draft-ietf-fax-tiff-fx-04.txt - File Format for Internet Fax appears to be ready to progress to Draft Standard. There are no problems with references, assuming that RFC 2302 or a successor text is sent forward at the same time. In addition, a detailed interworking report was prepared and previously circulated on this list which appears to meet all of the necessary interworking criteria. The related document RFC 2302 on TIFF Registration has no content changes, but requires an update to contact information, so that a new Internet Draft draft-ietf-fax-tiff-regbis-00.txt will be released as the current text. It could be sent for progression for either draft standard or as a BCP document (Best Current Practice). Since the content of this document primarily contains IANA registration content, I would suggest that it go forward as a BCP, so that it will not need to be progressed again. As usual, comments or suggestions on which way to go are welcome. The document draft-ietf-fax-service-v2-01.txt - A Simple Mode of Facsimile Using Internet Mail also appears to be very stable. However, it is now dependent on the progression of normative references to Draft Standard status. In particular, the RFC 2060 on IMAP4 and RFC 1891 on DSN are documents outside of the WG that need to progress in order to be referenced. Within the WG, there is a dependency on the successor documents for RFC 2303 and RFC 2304, as well as RFC 2301. There has been substantial documentation of interworking for RFC 2305, notably based on the results of 2 Fax Connect events, but there is a need for the results to be put in the right format and to complete the process of getting permissions from participants to use the data. In summary, the text for draft-ietf-fax-service-v2-01.txt is stable, but it is not yet ready to progress to draft standard due to its dependencies. The potential courses of action for this document seem to be: 1. Keep the document on hold as is until the references are ready and the interworking documentation is complete. 2. Submit the document in its current form and recycle at proposed standard level to create a new stable reference which can be submitted for draft std in 6 mths if the references progress during that time. I will plan to consult with the new chairs and the ADs on the best way to go here. The remaining documents in the WG Last Call are the revised texts based on RFC 2303 and 2304. The documents which went under the Last Call are: draft-ietf-fax-faxaddr-v2-00.txt - Minimal FAX address format in Internet Mail draft-ietf-fax-minaddr-v2-00.txt - lMinimal GSTN address format in Internet Mail No comments were made on the documents, so they appear to be very stable. However, documentation of interworking for these documents is still incomplete. In particular, the /T33S syntax has not yet been documented for interworking between 2 independent senders and receivers. The other portions of the document WERE implemented in multiple implementations at the Fax Connect events. Again, I urge implementors of Internet fax clients and gateways to come forward and help us to complete the necessary interworking tests and documentation. I have been aware of at least one implementation that might help us to complete these tests, but we need one more. I do not believe there are any issues in these documents concerning normative references. So, the choices for action on these documents seem to be: 1. Keep on hold until the interworking data is available 2. Publish the current texts, which are much easier to read but have no technical changes, recycling at proposed standard. This concludes the report on the WG Last Call. My thanks to all of the authors and implementors who have worked hard on these documents and on related deployments. I will consult with the new co-chairs and the ADs on the next steps for the documents. James Rafferty (outgoing) Chair, Internet Fax WG * ----------------------------------- James Rafferty Senior Product Manager, IP Telephony Brooktrout Technology 410 First Avenue Needham, MA 02494 USA Phone: +1-781-433-9462 Fax: 781-433-9268 Email/Internet Fax: jraff@brooktrout.com Alt Email: jrafferty@worldnet.att.net From owner-ietf-fax@mail.imc.org Wed Mar 8 10:42:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24093 for ; Wed, 8 Mar 2000 10:42:35 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA13510 for ietf-fax-bks; Wed, 8 Mar 2000 07:14:54 -0800 (PST) Received: from hose.pipex.net (hose.news.pipex.net [158.43.128.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13502; Wed, 8 Mar 2000 07:14:52 -0800 (PST) Received: from GK-VAIO (userah85.uk.uudial.com [62.188.133.16]) by hose.pipex.net (Postfix) with ESMTP id 674F7461A; Wed, 8 Mar 2000 15:15:30 +0000 (GMT) Message-Id: <4.2.2.20000308121547.00c0c810@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 08 Mar 2000 12:30:09 +0000 To: "Neystadt, John" From: Graham Klyne Subject: RE: [VPIM] Analogy to Content-Duration for Faxes Cc: IETF VPIM List , ietf-fax@imc.org, conneg WG In-Reply-To: <5B34AF33D291D311A06D0004AC1509D7C374C6@unity-mail.icomvers e.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John, Writing a draft sounds good to me. Submitting a draft is usually a good step to getting an idea considered seriously. An example whose procedural model you might wish to follow is the charset/language feature registration proposal written by Paul Hoffman. This was circulated and reviewed within and outside the conneg group, and has since been IETF-last-called as a private submission. There's a mailing list for review of new feature registrations (noted in RFC 2506). It would probably be sensible to at least notify the conneg list of any proposal you make, since some interested parties are here. But (beyond some initial registrations) it is not the purpose of the conneg WG to approve all new feature registrations. In your case (assuming VPIM has WG status), you may wish to present and progress it as a VPIM work item (with the chair's concurrence, of course). There might be a case for making it a fax WG item. BTW, as I understand it, an IETF-tree feature registration doesn't necessarily need to be standards track (though I think at least informational RFC publication is required). But, if you want to reference the feature normatively from another standards track specification, then I think it would need to be standards track. #g -- At 01:31 PM 3/8/00 +0200, Neystadt, John wrote: >So, what should be a way to advance with this, should I try to write a draft >for this feature? > >John Neystadt >john@neystadt.org >http://www.neystadt.org/john/ > > > > > -----Original Message----- > > From: Graham Klyne [mailto:GK@Dial.pipex.com] > > Sent: Wed, March 08, 2000 12:45 PM > > To: Neystadt, John > > Cc: conneg WG; IETF VPIM List; ietf-fax@imc.org > > Subject: RE: [VPIM] Analogy to Content-Duration for Faxes > > > > > > John, > > > > I think there's nothing wrong with a small RFC :-) > > > > has already gone > > forward for > > last call, and the IESG review is (at least) partially done. > > Also, there's > > not an obvious linkage between registration of "pages" and the > > "content-features:" header proposal, so I think they are > > better kept separate. > > > > BTW, I think Larry's proposal was always to register "pages", as you > > suggest, and that the reference to "UA-media" was simply a > > (subsidiary) > > possibility to qualify the kind of "page" being indicated. > > > > Regards, > > > > #g > > -- > > > > > > At 11:38 PM 3/7/00 +0200, Neystadt, John wrote: > > >ua-media doesn't fits well, we are not talking about user > > agents here. > > > > > >I think registering media feaure "pages" is a better one. > > > > > >What should be done to go forward with this. It seems to > > small item for an > > >RFC, can't we take tremp and add it into > > >draft-ietf-conneg-content-features.txt? > > > > > >John Neystadt > > >john@neystadt.org > > >http://www.neystadt.org/john/ > > > > > > > > > > > > > -----Original Message----- > > > > From: Larry Masinter [mailto:LM@att.com] > > > > Sent: Thu, February 10, 2000 4:35 AM > > > > To: ned.freed@innosoft.com > > > > Cc: Neystadt, John; IETF VPIM List; ietf-fax@imc.org > > > > Subject: RE: [VPIM] Analogy to Content-Duration for Faxes > > > > > > > > > > > > > > > > # > Content-Features: pages=10 > > > > > > > > # > to note a 10-page document. > > > > > > > > # Might even want to have an additional attribute to say what > > > > sort of "page" > > > > # you're talking about. > > > > > > > > RFC 2534 already registers 'ua-media' tag with values such as > > > > 'screen-paged' > > > > and 'stationery' (most likely the kind of pages you'd want > > > > with faxes), and > > > > a 'paper-size' tag with additional token values. At the time > > > > RFC 2534 was > > > > written, we were focusing mainly on media features for > > > > recipients rather > > > > than > > > > for content; you might still want to characterize a fax > > > > recipient as having > > > > a maximum number of pages its willing to receive, though. > > > > > > > > > > > > > > > > > > > > ------------ > > Graham Klyne > > (GK@ACM.ORG) > > > > ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Wed Mar 8 14:05:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01495 for ; Wed, 8 Mar 2000 14:05:39 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA16720 for ietf-fax-bks; Wed, 8 Mar 2000 10:28:05 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16716 for ; Wed, 8 Mar 2000 10:28:04 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA20609; Wed, 8 Mar 2000 10:28:11 -0800 (PST) Date: Wed, 8 Mar 2000 10:28:11 -0800 (PST) From: Dan Wing To: James Rafferty cc: "'IETF Fax List'" , "'Keith Moore'" , "'Ned Freed'" , =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , "'H. Tamura'" , "'Claudio Allocchio'" Subject: Re: [Fax] WG Last Call Report on Progressing Simple Mode Documents In-Reply-To: <11740AB18BD4D111BE8F00A0C9B8044F0227EE97@nhmail1.admin.brooktrout.com> Message-ID: <0003081024290.11321-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 8 Mar 2000 09:24 -0500, James Rafferty wrote: > The document draft-ietf-fax-service-v2-01.txt - A Simple Mode of > Facsimile Using Internet Mail also appears to be very stable. > However, it is now dependent on the progression of normative > references to Draft Standard status. In particular, the RFC 2060 on > IMAP4 and RFC 1891 on DSN are documents outside of the WG that need to > progress in order to be referenced. draft-ietf-fax-service-v2-01.txt's reference to RFC1891 is completely non-normative. The reference to RFC1891 can safely be completely removed. We only need to reference RFC1894. The only section that mentions either RFC1891 or 1894 is: 2.3.1 Delivery failure This section describes existing requirements for Internet mail, rather than indicating special requirements for IFax devices. In the event of relay failure, the sending relay MUST generate a failure message, which SHOULD be in the format of a DSN. [14,15] [14] is RFC1894 (which describes the format of a non-delivery notification message), and [15] is RFC1891 (which describes the SMTP service extension). > Within the WG, there is a dependency on the successor documents for > RFC 2303 and RFC 2304, as well as RFC 2301. -Dan Wing From owner-ietf-fax@mail.imc.org Wed Mar 8 16:39:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16066 for ; Wed, 8 Mar 2000 16:39:22 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA19176 for ietf-fax-bks; Wed, 8 Mar 2000 13:10:53 -0800 (PST) Received: from kiwi.equinix.com (kiwi.equinix.com [207.20.85.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA19166; Wed, 8 Mar 2000 13:10:48 -0800 (PST) Received: (from hardie@localhost) by kiwi.equinix.com (8.9.3/8.9.3) id NAA26200; Wed, 8 Mar 2000 13:11:12 -0800 (PST) Message-Id: <200003082111.NAA26200@kiwi.equinix.com> Subject: Re: [VPIM] Analogy to Content-Duration for Faxes To: John_Neystadt@icomverse.com (Neystadt, John) Date: Wed, 8 Mar 2000 13:11:12 -0800 (PST) Cc: vpim@lists.neystadt.org (IETF VPIM List), ietf-fax@imc.org, ietf-medfree@imc.org (conneg WG) In-Reply-To: <5B34AF33D291D311A06D0004AC1509D7C374C6@unity-mail.icomverse.com> from "Neystadt, John" at Mar 08, 2000 01:31:36 PM From: hardie@equinix.com Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL1] 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 John, Writing a draft for the feature is the correct next step for a feature to be considered in the unfaceted IETF registration tree. Please cc: the conneg working group when the internet drafts editor issues it, but do not request it be issued as a working document of the conneg group. The area directors do not wish the conneg group to become a permanent working group for features; they prefer that features, like MIBs, be definted by the groups which need them. If you have further questions on the administratrivia, please let me know. regards, Ted Hardie chair, conneg > > So, what should be a way to advance with this, should I try to write a draft > for this feature? > > John Neystadt > john@neystadt.org > http://www.neystadt.org/john/ > > > > > -----Original Message----- > > From: Graham Klyne [mailto:GK@Dial.pipex.com] > > Sent: Wed, March 08, 2000 12:45 PM > > To: Neystadt, John > > Cc: conneg WG; IETF VPIM List; ietf-fax@imc.org > > Subject: RE: [VPIM] Analogy to Content-Duration for Faxes > > > > > > John, > > > > I think there's nothing wrong with a small RFC :-) > > > > has already gone > > forward for > > last call, and the IESG review is (at least) partially done. > > Also, there's > > not an obvious linkage between registration of "pages" and the > > "content-features:" header proposal, so I think they are > > better kept separate. > > > > BTW, I think Larry's proposal was always to register "pages", as you > > suggest, and that the reference to "UA-media" was simply a > > (subsidiary) > > possibility to qualify the kind of "page" being indicated. > > > > Regards, > > > > #g > > -- > > > > > > At 11:38 PM 3/7/00 +0200, Neystadt, John wrote: > > >ua-media doesn't fits well, we are not talking about user > > agents here. > > > > > >I think registering media feaure "pages" is a better one. > > > > > >What should be done to go forward with this. It seems to > > small item for an > > >RFC, can't we take tremp and add it into > > >draft-ietf-conneg-content-features.txt? > > > > > >John Neystadt > > >john@neystadt.org > > >http://www.neystadt.org/john/ > > > > > > > > > > > > > -----Original Message----- > > > > From: Larry Masinter [mailto:LM@att.com] > > > > Sent: Thu, February 10, 2000 4:35 AM > > > > To: ned.freed@innosoft.com > > > > Cc: Neystadt, John; IETF VPIM List; ietf-fax@imc.org > > > > Subject: RE: [VPIM] Analogy to Content-Duration for Faxes > > > > > > > > > > > > > > > > # > Content-Features: pages=10 > > > > > > > > # > to note a 10-page document. > > > > > > > > # Might even want to have an additional attribute to say what > > > > sort of "page" > > > > # you're talking about. > > > > > > > > RFC 2534 already registers 'ua-media' tag with values such as > > > > 'screen-paged' > > > > and 'stationery' (most likely the kind of pages you'd want > > > > with faxes), and > > > > a 'paper-size' tag with additional token values. At the time > > > > RFC 2534 was > > > > written, we were focusing mainly on media features for > > > > recipients rather > > > > than > > > > for content; you might still want to characterize a fax > > > > recipient as having > > > > a maximum number of pages its willing to receive, though. > > > > > > > > > > > > > > > > > > > > ------------ > > Graham Klyne > > (GK@ACM.ORG) > > > > > From owner-ietf-fax@mail.imc.org Thu Mar 9 08:24:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29997 for ; Thu, 9 Mar 2000 08:24:48 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA28533 for ietf-fax-bks; Thu, 9 Mar 2000 04:53:11 -0800 (PST) Received: from dervish.mail.pipex.net (dervish.mail.pipex.net [158.43.192.70]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA28528 for ; Thu, 9 Mar 2000 04:53:09 -0800 (PST) Received: (qmail 20023 invoked from network); 9 Mar 2000 12:53:53 -0000 Received: from userev60.uk.uudial.com (HELO GK-VAIO) (62.188.17.243) by smtp.dial.pipex.com with SMTP; 9 Mar 2000 12:53:53 -0000 Message-Id: <4.2.2.20000309104653.00a3c630@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 09 Mar 2000 11:40:48 +0000 To: Hiroshi Tamura , ietf-fax@imc.org From: Graham Klyne Subject: Re: I-D ACTION:draft-ietf-fax-content-negotiation-00.txt In-Reply-To: <19991026133512I.tamura@toda.ricoh.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tamura-san, I am reviewing the comments you made some time ago concerning the fax negotiation draft. At 04:35 AM 10/26/99 +0000, Hiroshi Tamura wrote: >Hi, > >1 3.3 > >There are the following sentences. >" > If the sender is no longer able to send message data for any > reason, it MUST send a message to the receiver indicating a failed > transfer. It SHOULD also generate a report for the sender > indicating the failure. > > [[[Discuss this last paragraph.]]] >" > >In this case, what kind of messages do SENDER send to RECEIVER ? This is a very good question. At first, I had thought that an ordinary text or image message simply saying something like "The alternative data you have requested is no longer available". But on reflection, I wonder if this is enough: (a) an ordinary message conveys no information that the receiver might be able to use to print the data originally received (assuming it was buffered), or to otherwise indicate failure. (b) the failure information would not be available in a language neutral form for ocalized presentation of the problem. So now, I am thinking that it might be reasonable to define a multipart/report based format for carrying diagnostic information from sender to receiver. The general format would be very like DSN or MDN, but I think a different report-type would be needed. So my question to everyone is: would this be a reasonable thing to define, or is it introducing additional complexity for insufficient gain? If a new report type is to be introduced for this purpose, I do think it should be introduced sooner rather than later, as recognition would then become part of the specification for content negotiation and hence avoid backward-compatibility issues of introducing it later. NOTE: this new report type would be sent only after the receiver has indicated understanding of the negotiation protocol elements, so it wouldn't impact "legacy" receivers. >2 "Content-alternative" and 'Alternative-preferred' > >I think more than two "alternative"s cat be described >in the first Sender's message, >by using of more than "Content-alternative" headers. You are correct -- I have added a NOTE to my working copy to clarify this point. See also section 3.1.3 of the current (-00) draft. >Receiver cannot specify the exact one that it wants. >'Alternative-preferred' disposition modifier is only defined. This is intentional, and quite fundamental to the negotiation design. Some rationale is set out at the start of section 3, but this might need to be clarified. Speifically: (a) This more closely matches the style of T.30 content negotiation. (b) This approach provides for clean integration with the current extended mode specification. (c) It builds upon existing e-mail mechanisms in a consistent fashion. (d) It allows for cases (e.g. dynamically generated content) where it is not feasible to enumerate the alternatives available. I shall add an additional clarifying NOTE in the document. >Another sub-modifier(?) is necessary for it. ... for the reasons given above, I think this is something to be avoided. >And, > >Receiver cannot judge whether the message from Sender is >the first one or the second one. In section 3.3, the specification says that 'alternative-available' should not be indicated when the sender is responding to 'alternative-preferred'. This is stated so that the negotiation process does not loop. Does this adequately address your concern? >Sometimes, Receiver may want to know the message is the >second one. When Receiver returns 'Alternative-preferred', >it waits for the 'Alternative' of the first message. > >In some implementation, if Receiver do not receive >the second one within some fixed time, it may print >the first message. > >Some new header or something will solve it. Or, is this to suppress double-printing of a message? If so, I would suggest introducing another disposition request modifier, say 'alternative-resend', to be used by the sender when responding to 'alternative-preferred'. Then, a receiver, if it cannot match the 'alternative-resend' to an outstanding 'alternative-preferred' might assume that the original message was printed after all and (maybe) discard the alternative. (NOTE: the specification could define 'alternative-resend', or similar, but I think the receiver's handling of this information would be an implementation issue, not part of the specfication.) In the final analysis, I think multiple message printing cannot be completely prevented (e.g. see RFC 1047). While it is desirable to avoid frequent duplicate message displays, I think it is less harmful than avoidable loss of messages. >On the whole, there are lots of matters to fix, as in [[[]]]. >There may be other matters that are not descibed here. Yes, indeed. My feeling is that many of these issues will drop out quite easily when we have finalized some key outstanding issues. Thank you very much for your comments. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Thu Mar 9 20:58:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17827 for ; Thu, 9 Mar 2000 20:58:52 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA12735 for ietf-fax-bks; Thu, 9 Mar 2000 17:24:13 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA12731 for ; Thu, 9 Mar 2000 17:24:11 -0800 (PST) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id KAA20658; Fri, 10 Mar 2000 10:24:56 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id KAA18613; Fri, 10 Mar 2000 10:24:53 +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 KAA00699; Fri, 10 Mar 2000 10:20:23 +0900 (JST) To: GK@dial.pipex.com Cc: ietf-fax@imc.org Subject: Re: I-D ACTION:draft-ietf-fax-content-negotiation-00.txt In-Reply-To: <4.2.2.20000309104653.00a3c630@pop.dial.pipex.com> References: <19991026133512I.tamura@toda.ricoh.co.jp> <4.2.2.20000309104653.00a3c630@pop.dial.pipex.com> X-Mailer: Mew version 1.94.1 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: <20000310102821J.tamura@toda.ricoh.co.jp> Date: Fri, 10 Mar 2000 10:28:21 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 107 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Klyne-san, > > If the sender is no longer able to send message data for any > > reason, it MUST send a message to the receiver indicating a failed > > transfer. It SHOULD also generate a report for the sender > > indicating the failure. > >In this case, what kind of messages do SENDER send to RECEIVER ? > > This is a very good question. At first, I had thought that an ordinary > text or image message simply saying something like "The alternative data > you have requested is no longer available". But on reflection, I wonder if > this is enough: > > (a) an ordinary message conveys no information that the receiver might be > able to use to print the data originally received (assuming it was > buffered), or to otherwise indicate failure. > > (b) the failure information would not be available in a language neutral > form for ocalized presentation of the problem. OK. I understand you. > So now, I am thinking that it might be reasonable to define a > multipart/report based format for carrying diagnostic information from > sender to receiver. The general format would be very like DSN or MDN, but > I think a different report-type would be needed. Yes > So my question to everyone is: would this be a reasonable thing to define, > or is it introducing additional complexity for insufficient gain? I prefer the simple method. > >2 "Content-alternative" and 'Alternative-preferred' > > > >I think more than two "alternative"s cat be described > >in the first Sender's message, > >by using of more than "Content-alternative" headers. > > You are correct -- I have added a NOTE to my working copy to clarify this > point. See also section 3.1.3 of the current (-00) draft. > > >Receiver cannot specify the exact one that it wants. > >'Alternative-preferred' disposition modifier is only defined. > I shall add an additional clarifying NOTE in the document. OK. > >Receiver cannot judge whether the message from Sender is > >the first one or the second one. I mean, the first try message or the second try message after responding with 'alternative-preferred'. > >Sometimes, Receiver may want to know the message is the > >second one. When Receiver returns 'Alternative-preferred', > >it waits for the 'Alternative' of the first message. > > > >In some implementation, if Receiver do not receive > >the second one within some fixed time, it may print > >the first message. > > > >Some new header or something will solve it. > > Or, is this to suppress double-printing of a message? Yes, one reason. > If so, I would suggest introducing another disposition request modifier, > say 'alternative-resend', to be used by the sender when responding to > 'alternative-preferred'. Then, a receiver, if it cannot match the > 'alternative-resend' to an outstanding 'alternative-preferred' might assume > that the original message was printed after all and (maybe) discard the > alternative. One idea. > (NOTE: the specification could define 'alternative-resend', or similar, > but I think the receiver's handling of this information would be an > implementation issue, not part of the specfication.) You may be right. Unfortunately, I do not cover the all cases. There are lots of cases, I think. Some should be included in it and Others should not be included(to be implementation issue). I cannot separate now. Anyway, I look forward to the updated version. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@mail.imc.org Fri Mar 10 07:19:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16830 for ; Fri, 10 Mar 2000 07:19:48 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA13584 for ietf-fax-bks; Fri, 10 Mar 2000 03:50:47 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA13575 for ; Fri, 10 Mar 2000 03:50:37 -0800 (PST) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id UAA19946 for ; Fri, 10 Mar 2000 20:51:28 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id UAA17019 for ; Fri, 10 Mar 2000 20:51:28 +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 UAA00726 for ; Fri, 10 Mar 2000 20:47:13 +0900 (JST) To: ietf-fax@imc.org Subject: Proposed Agenda at Adelaide meeting X-Mailer: Mew version 1.94.1 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: <20000310205514T.tamura@toda.ricoh.co.jp> Date: Fri, 10 Mar 2000 20:55:14 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 59 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Colleagues, The following is a proposed Agenda for Adelaide meeting. We have a slot on Thursday afternoon(1530-1730) at this time. About drafts in action, I put the name of drafts after submission. Any suggestions or comments are welcome. If you have any matters you would like to introduce, please let me know soon. ---------------------------------------------------------- Internet Fax Extensions (faxext) Chairs: Claudio Allocchio Hiroshi Tamura Agenda: 5 min Opening - Introduction of new co-chairs - bashing Agenda 15 min Introduction of new charter - Getting consensus of the charter 15 min Status of drafts after WG Last Call - Drafts waiting for IETF approval draft-ietf-fax-feature-schema-v2-01.txt draft-ietf-fax-feature-T30-mapping-03.txt - Draft standards waiting for IETF approval draft-ietf-fax-tiff-fx-04.txt draft-ietf-fax-service-v2-01.txt draft-ietf-fax-faxaddr-v2-00.txt draft-ietf-fax-minaddr-v2-00.txt 60 min Review of drafts in action 15 min draft for timely delivery 15 min draft for content negotiaton for fax 15 min draft for FFPIM 15 min draft of Implementors Guide for Simple and Extended mode 10 min On-going works 10 min TIFF-FX extension 10 min Introduction of cooperation with ITU - Report of SG8 February Meeting - Plan for ITU-T 5 min Other businesses and Closing ---------------------------------------------------------- Regards, -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@mail.imc.org Fri Mar 10 12:48:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06210 for ; Fri, 10 Mar 2000 12:48:24 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA23825 for ietf-fax-bks; Fri, 10 Mar 2000 09:00:25 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23821 for ; Fri, 10 Mar 2000 09:00:24 -0800 (PST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Fri, 10 Mar 2000 11:01:04 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Mar 2000 11:00:48 -0600 Message-ID: <456E6DB7180ED3118A670000F8BDCA29021BADF9@zcard00p.ca.nortel.com> From: "Glenn Parsons" To: "'IETF VPIM List'" Cc: "'ietf-fax@imc.org'" Subject: RE: [VPIM] Analogy to Content-Duration for Faxes Date: Fri, 10 Mar 2000 11:00:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8AB2.2DB7395C" 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_01BF8AB2.2DB7395C Content-Type: text/plain; charset="windows-1252" Now I remember :-) It was one of the opitions described in for message length indicator. I have exerted the section below. The original intent of this was for clients to get this information via IMAP and present it on the client. Despite the ugliness of subject overloading, I am afraid that is what a lot of products implement. I guess the question is do we want to endorse this, or create a better mechanism (like the Conneg suggestion or one of the others below). If we choose the latter, the client vendors have to agree to implement it, or the industry will likely tend to what they do now. Glenn. 8. Message Length Indicator In the cases of large attachments, small clients and slow links there is also a need for the client to see the length of the message in a suitable format before opening it. A message length indicator suitable for voicemail and fax should indicate the length of the message using number of seconds for a voice message and using number of pages for a fax message. The client MUST support the chosen method. There are three suggested methods and among them, 8.3 is favoured: 8.1 MIME Header Content-Duration as described in RFC 2424 [7] For fax messages a new MIME Header, Content-Page-Length, would be defined, similar to Content-Duration with the exception that number of pages would be specified, rather than number of seconds. (e.g. Content-Page-Length:3). This would be created at originator. 8.2 FETCH item USERSIZE similar to FETCH items described in IMAP4rev1 [3]. This would be creat! ed at reception. 8.2.1 USERSIZE is a non-negative number. Its meaning depends on document type. C: abc FETCH 1:2 (USERSIZE) S: *1 FETCH (12) S: *2 FETCH (57) S: abc FETCH completed. 8.2.2 USERSIZE is a pair of number and unit. There is a small set of unit tokens. C: abc FETCH 1:2 (USERSIZE) S: *1 FETCH (12 pages) S: *2 FETCH (57 seconds) S: abc FETCH completed. 8.2.3 USERSIZE is a sequence of pairs, in case something extends in more than one unit. C: abc FETCH 1:2 (USERSIZE) S: *1 FETCH (12 lines) S: *1 FETCH (57 pages 6 hours) S: abc FETCH completed. Servers that support USERSIZE SHOULD list the USERSIZE capability in response to the CAPABILITY command. 8.3 Message length indicated as a parameter of an existing Header Field [4]. This would be created at the source. This method would allow the message length to be passed to the client by default. 8.3.1 Content-Type Header Field Content-Type=audio/*; length=50 Content-Type=image/tiff; pages=3 8.3.2 Subject Header Field Subject=Voice Message (0:04) Subject=Fax Message (3) The advantage of the subject field is that it is automatically displayed to the user. > ---------- > From: Parsons, Glenn [NORSE:6L45:EXCH] > Sent: Friday, February 4, 2000 6:08 am > To: vpim@lists.neystadt.org > Cc: 'ietf-fax@imc.org' > Subject: RE: [VPIM] Analogy to Content-Duration for Faxes > > At one point we had proposed a 'Content-Length' header specifically for > fax page count. I cannot remember if it was ever included in an RFC or > not. > > In practice, we have found it more practical to put thie information in > the Subject field. Then the user will see the info in their GUI. > > Cheers, > Glenn. > > ---------- > From: Murray, Doug > Sent: Thursday, February 3, 2000 6:11 pm > To: 'Neystadt, John'; vpim@lists.neystadt.org > Subject: RE: [VPIM] Analogy to Content-Duration for Faxes > > Yes, it is very useful to have content duration in meaningful units > such as > seconds of audio (or video), pages of fax, etc. Most e-mail clients > will not > display this information, however. > > The place that this information is most useful is within a TUI where > it is > useful to announce the number of pages in a fax, Word document or > whatever > so the recipient can decide whether to forward the document to a fax > machine. > > -----Original Message----- > From: Neystadt, John [mailto:John_Neystadt@icomverse.com] > Sent: Thursday, January 27, 2000 3:27 AM > To: vpim@lists.neystadt.org > Subject: [VPIM] Analogy to Content-Duration for Faxes > > > Hi! > > I wonder if anybody came to need of Analogy to Content-Duration for > Faxes to > indicate the number of pages. This is handy to present GUI idication > of fax > size in pages (as in seconds for voice) instead of KBs. > > Does somebody needs this in addition to us? > > Regards, > > John Neystadt > > > > > ------_=_NextPart_001_01BF8AB2.2DB7395C Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable RE: [VPIM] Analogy to Content-Duration for Faxes

Now I remember :-)

It was one of the opitions = described in <draft-ema-vpim-imap-01.txt> for message length = indicator.  I have exerted the section below.  The original = intent of this was for clients to get this information via IMAP and = present it on the client.

Despite the ugliness of = subject overloading, I am afraid that is what a lot of products = implement.  I guess the question is do we want to endorse this, or = create a better mechanism (like the Conneg suggestion or one of the = others below).  If we choose the latter, the client vendors have = to agree to implement it, or the industry will likely tend to what they = do now.

Glenn.

=0D
8.  Message Length = Indicator=0D=0D     In the cases of large = attachments, small clients and slow links =0D     = there is also a need for the client to see the length of the = =0D     message in a suitable format before opening = it. =0D=0D     A message length indicator suitable = for voicemail and fax should =0D     indicate the = length of the message using number of seconds for a = =0D     voice message and using number of pages for = a fax message.  The =0D     client MUST = support the chosen method.  There are three suggested = =0D     methods and among them, 8.3 is = favoured:=0D=0D   8.1  MIME Header Content-Duration as = described in RFC 2424 [7]=0D=0D     For fax = messages a new MIME Header, Content-Page-Length, would be = =0D     defined, similar to Content-Duration with = the exception that number =0D     of pages would be = specified, rather than number of seconds. (e.g. = =0D     Content-Page-Length:3).  This would be = created at originator.=0D=0D   8.2  FETCH item USERSIZE = similar to FETCH items described in =0D     = IMAP4rev1 [3].  This would be created at = reception.=0D=0D   8.2.1  USERSIZE is a non-negative = number.  Its meaning depends on =0D     = document type.=0D=0D     C: abc FETCH 1:2 = (USERSIZE)=0D     S: *1 FETCH = (12)=0D     S: *2 FETCH = (57)=0D     S: abc FETCH = completed.=0D=0D   8.2.2  USERSIZE is a pair of number = and unit.  There is a small set =0D     of = unit tokens.=0D=0D     C: abc FETCH 1:2 = (USERSIZE)=0D     S: *1 FETCH (12 = pages)=0D     S: *2 FETCH (57 = seconds)=0D     S: abc FETCH = completed.=0D=0D   8.2.3  USERSIZE is a sequence of = pairs, in case something extends in=0D     more = than one unit.=0D=0D     C: abc FETCH 1:2 = (USERSIZE)=0D     S: *1 FETCH (12 = lines)=0D     S: *1 FETCH (57 pages 6 = hours)=0D     S: abc FETCH = completed.=0D=0D     Servers that support USERSIZE = SHOULD list the USERSIZE capability =0D     in = response to the CAPABILITY command.=0D=0D   8.3  Message = length indicated as a parameter of an existing Header Field [4].  = =0D     This would be created at the source.  = This method would allow the message =0D     length = to be passed to the client by default. = =0D=0D        8.3.1  = Content-Type Header Field=0D        = Content-Type=3Daudio/*; = length=3D50=0D        = Content-Type=3Dimage/tiff; = pages=3D3=0D=0D        8.3.2 Subject = Header Field=0D        = Subject=3DVoice Message = (0:04)=0D        Subject=3DFax = Message (3)=0D=0D        The = advantage of the subject field is that it is automatically = displayed=0D        to the = user.=0D



    ----------
    From:   Parsons, Glenn [NORSE:6L45:EXCH]
    Sent:   Friday, February 4, 2000 6:08 am
    To:     = vpim@lists.neystadt.org
    Cc:     = 'ietf-fax@imc.org'
    Subject: =        RE: = [VPIM] Analogy to Content-Duration for Faxes

    At one point we had proposed = a 'Content-Length' header specifically for fax page count.  I = cannot remember if it was ever included in an RFC or not.

    In practice, we have found it = more practical to put thie information in the Subject field.  Then = the user will see the info in their GUI.

    Cheers,
    Glenn.

      ----------
      From:   Murray, Doug
      Sent:   Thursday, February 3, 2000 6:11 pm
      To:     = 'Neystadt, John'; = vpim@lists.neystadt.org
      Subject: =        RE: = [VPIM] Analogy to Content-Duration for Faxes

      Yes, it is very useful to have = content duration in meaningful units such as
      seconds of audio (or video), pages = of fax, etc. Most e-mail clients will not
      display this information, = however.

      The place that this information is = most useful is within a TUI where it is
      useful to announce the number of = pages in a fax, Word document or whatever
      so the recipient can decide whether = to forward the document to a fax
      machine.

      -----Original Message-----
      From: Neystadt, John = [mailto:John_Neystadt@icomver= se.com]
      Sent: Thursday, January 27, 2000 = 3:27 AM
      To: vpim@lists.neystadt.org
      Subject: [VPIM] Analogy to = Content-Duration for Faxes


      Hi!

      I wonder if anybody came to need of = Analogy to Content-Duration for Faxes to
      indicate the number of pages. This = is handy to present GUI idication of fax
      size in pages (as in seconds for = voice) instead of KBs.

      Does somebody needs this in addition = to us?

      Regards,

      John Neystadt





------_=_NextPart_001_01BF8AB2.2DB7395C-- From owner-ietf-fax@mail.imc.org Fri Mar 10 15:12:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28237 for ; Fri, 10 Mar 2000 15:12:12 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA25892 for ietf-fax-bks; Fri, 10 Mar 2000 11:32:24 -0800 (PST) Received: from mail.rdc1.nj.home.com (imail@ha1.rdc1.nj.home.com [24.3.128.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25888 for ; Fri, 10 Mar 2000 11:32:23 -0800 (PST) Received: from home.com ([24.3.205.203]) by mail.rdc1.nj.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000310193315.UADC2345.mail.rdc1.nj.home.com@home.com>; Fri, 10 Mar 2000 11:33:15 -0800 Message-ID: <38C94DF8.A3025D21@home.com> Date: Fri, 10 Mar 2000 14:33:12 -0500 From: "Herman R. Silbiger" Reply-To: hsilbiger@ieee.org Organization: APPLICOM X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Vaudreuil CC: IETF VPIM List , ietf-fax@imc.org Subject: Re: draft-vaudreuil-enum-e164dir-00.doc References: <200003082111.NAA26200@kiwi.equinix.com> 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 The correct reference for E.164 is: Recommendation E.164/I.331 (05/97) - The international public telecommunication numbering plan. I think the internet draft should refer to the current version of E.164 and its contents. Herman From owner-ietf-fax@mail.imc.org Fri Mar 10 16:18:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21937 for ; Fri, 10 Mar 2000 16:18:30 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA26829 for ietf-fax-bks; Fri, 10 Mar 2000 12:44:38 -0800 (PST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26825 for ; Fri, 10 Mar 2000 12:44:37 -0800 (PST) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Fri, 10 Mar 2000 15:44:57 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Mar 2000 15:44:56 -0500 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24919C13@bcarua63.ca.nortel.com> From: "Anne Brown" To: "Glenn Parsons" Cc: "'V PIM'" Subject: RE: VPIM directory Date: Fri, 10 Mar 2000 15:44:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8AD1.7E74C7E6" 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_01BF8AD1.7E74C7E6 Content-Type: text/plain; charset="iso-8859-1" Good idea Glenn, draft-vaudreuil-enum-e164-00.txt is the result of combining mine and Greg's work in ENUM and various industry forums (EMA, ICMA, TMA). It obsoletes Greg's drafts draft-vaudreuil-vpimdir-ars-00.txt and draft-vaudreuil-vpimdir-principles-00.txt. The two drafts draft-ema-vpimdir-schema-01.txt and draft-vaudreuil-vpimdir-avs.txt will be combined into one new draft in the future discussing the VPIM-specific directory schema. draft-brown-e164-01.txt still stands as a separate proposal which has a wider scope than ENUM. There are several important requirements that were taken out of draft-vaudreuil-vpimdir-principles-00.txt that should go in the next version of draft-enum-rqmts-00.txt. Any changes to the requirements draft, however, will be discussed on the ENUM list first. Regards, Anne -----Original Message----- From: Parsons, Glenn [NORSE:6L45:EXCH] Sent: March 10, 2000 3:26 PM To: Brown, Anne [NORSE:5N00:EXCH] Subject: VPIM directory Anne, Could you send a message to the VPIM list explaining the relevance of ? Does it obsolete draft-brown-e164-01.txt? Does it obsolete Greg's various drafts draft-vaudreuil-vpimdir-*? What about draft-ema-vpimdir-schema-01.txt? Is that fine as is and we should put out a last call on it? Thanks, Glenn. ------_=_NextPart_001_01BF8AD1.7E74C7E6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: VPIM directory

Good idea Glenn,

draft-vaudreuil-enum-e164-00.txt is = the result of combining mine and Greg's work in ENUM and various = industry forums (EMA, ICMA, TMA).  It obsoletes Greg's drafts = draft-vaudreuil-vpimdir-ars-00.txt and = draft-vaudreuil-vpimdir-principles-00.txt.  The two drafts = draft-ema-vpimdir-schema-01.txt and draft-vaudreuil-vpimdir-avs.txt = will be combined into one new draft in the future discussing the = VPIM-specific directory schema.  draft-brown-e164-01.txt still = stands as a separate proposal which has a wider scope than ENUM.  = There are several important requirements that were taken out of = draft-vaudreuil-vpimdir-principles-00.txt that should go in the next = version of draft-enum-rqmts-00.txt.  Any changes to the = requirements draft, however, will be discussed on the ENUM list = first.

Regards,
Anne

      -----Original = Message-----
      From:   Parsons, Glenn = [NORSE:6L45:EXCH]
      Sent:   March 10, 2000 3:26 PM
      To:     Brown, Anne [NORSE:5N00:EXCH]
      Subject:       = VPIM directory

      Anne,

      Could you send a message to the VPIM list = explaining the relevance of <draft-vaudreuil-enum-e164dir-00.txt>?

      Does it obsolete = draft-brown-e164-01.txt?

      Does it obsolete Greg's various drafts = draft-vaudreuil-vpimdir-*?

      What about = draft-ema-vpimdir-schema-01.txt?  Is that fine as is and we should = put out a last call on it?

      Thanks,
      Glenn.

------_=_NextPart_001_01BF8AD1.7E74C7E6-- From owner-ietf-fax@mail.imc.org Fri Mar 10 18:40:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11762 for ; Fri, 10 Mar 2000 18:40:53 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA28288 for ietf-fax-bks; Fri, 10 Mar 2000 14:24:27 -0800 (PST) Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28283 for ; Fri, 10 Mar 2000 14:24:26 -0800 (PST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Fri, 10 Mar 2000 16:07:36 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Mar 2000 16:06:43 -0600 Message-ID: <456E6DB7180ED3118A670000F8BDCA29021BAE04@zcard00p.ca.nortel.com> From: "Glenn Parsons" To: "'IETF VPIM List'" Cc: "'EMA VPIM List'" , "'ietf-fax@imc.org'" Subject: VPIM Addressing Date: Fri, 10 Mar 2000 16:06:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF8ADC.EAFEEADA" X-Orig: 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_000_01BF8ADC.EAFEEADA Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8ADC.EAFEEADA" ------_=_NextPart_001_01BF8ADC.EAFEEADA Content-Type: text/plain; charset="windows-1252" Folks, I have updated the VPIM addressing draft based on some of the changes in the new GSTN Addressing document that was recently approved for publication. For example, some IANA registration sections were added as appendices. Of note, as well, is that I added additional syntax to distinguish between AMIS-A and AMIS-D submission addresses. I'dd appreciate some feedback from the AMIS implementors on the accuracy of this. Let me know if you have any comments. Thanks, Glenn. > <> > > > > ------_=_NextPart_001_01BF8ADC.EAFEEADA Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable VPIM Addressing

Folks,

I have updated the VPIM = addressing draft based on some of the changes in the new GSTN = Addressing document that was recently approved for publication.  = For example, some IANA registration sections were added as = appendices.

Of note, as well, is that I = added additional syntax to distinguish between AMIS-A and AMIS-D = submission addresses.  I'dd appreciate some feedback from the AMIS = implementors on the accuracy of this.

Let me know if you have any = comments.

Thanks,
Glenn.

= <<draft-ema-vpim-address-01.txt>>




------_=_NextPart_001_01BF8ADC.EAFEEADA-- ------_=_NextPart_000_01BF8ADC.EAFEEADA Content-Type: application/applefile; name="draft-ema-vpim-address-01.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ema-vpim-address-01.txt" Content-Transfer-Encoding: base64 AAUWAAACAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAASgAAABAAAAAJAAAAWgAAACAAAAADAAAA egAAAB0AAAABAAAAlwAAa5a07tiYtO7ZbwAAAAAAAAAAVEVYVE1TV0QBAAPAAJwAAAAAAAAAAAAA AAAAAAAAAABkcmFmdC1lbWEtdnBpbS1hZGRyZXNzLTAxLnR4dA0KICAgICAgSW50ZXJuZXQgRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR2xlbm4gUGFyc29ucw0K ICAgICAgRXhwaXJlcyBpbiBzaXggbW9udGhzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IE5vcnRlbCBOZXR3b3Jrcw0KICAgICAgDQogICAgICBEb2N1bWVudDogPGRyYWZ0LWVtYS12cGlt LWFkZHJlc3MtMDEudHh0PiAgICAgICAgICAgIE1hcmNoIDEwLCAyMDAwDQogICAgICAgDQogICAg ICAgDQogICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVlBJTSBBZGRyZXNz aW5nIA0KICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICA8ZHJhZnQtZW1hLXZwaW0tYWRk cmVzcy0wMS50eHQ+IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQogICAgICAgDQogICAgICAgDQogICAgICBTdGF0dXMgb2YgdGhpcyBNZW1vIA0KICAgICAgIA0K ICAgICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBj b25mb3JtYW5jZSB3aXRoIA0KICAgICAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBS RkMyMDI2LiAgDQogICAgICAgDQogICAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9j dW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyANCiAgICAgIFRhc2sgRm9yY2UgKElF VEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuIE5vdGUgdGhhdCANCiAgICAg IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIElu dGVybmV0LQ0KICAgICAgRHJhZnRzLiANCiAgICAgICANCiAgICAgIEludGVybmV0IERyYWZ0cyBh cmUgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzIGFuZCBtYXkgYmUgDQogICAgICB1 cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkg dGltZS4gIEl0IA0KICAgICAgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQgRHJhZnRz IGFzIHJlZmVyZW5jZSBtYXRlcmlhbCBvciB0byANCiAgICAgIGNpdGUgdGhlbSBvdGhlciB0aGFu IGFzIGEgIndvcmsgaW4gcHJvZ3Jlc3MiLiANCiAgICAgICANCiAgICAgIFRoZSBsaXN0IG9mIGN1 cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCiAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dCANCiAgICAgICANCiAgICAgIFRo ZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNz ZWQgYXQgIA0KICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCANCiAgICAgICAN CiAgICAgICANCiAgICAgIENvcHlyaWdodCBOb3RpY2UgDQogICAgICAgICAgICANCiAgICAgIENv cHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDApLiAgQWxsIFJpZ2h0cyBSZXNl cnZlZC4gDQogICAgICAgICAgICANCiAgICAgICANCiAgICAgIE92ZXJ2aWV3IA0KICAgICAgICAg ICAgDQogICAgICBUaGlzIGRvY3VtZW50IGxpc3RzIHRoZSB2YXJpb3VzIFZQSU0gZW1haWwgYWRk cmVzc2VzIHRoYXQgYXJlIA0KICAgICAgY3VycmVudGx5IGluIGNvbW1vbiB1c2UgYW5kIGRlZmlu ZXMgc2V2ZXJhbCBuZXcgYWRkcmVzcyBmb3JtYXRzIGZvciANCiAgICAgIHNwZWNpYWwgY2FzZSB1 c2FnZS4gVGhpcyBkcmFmdCBpcyBhIHBhcnQgb2YgdGhlIGNoYXJ0ZXIgb2YgdGhlIElFVEYgDQog ICAgICBWUElNIEJPRi9XRy4gDQogICAgICAgICAgICANCiAgICAgIFRoZSBWUElNIFdHIGhvbWUg cGFnZSBpczogIGh0dHA6Ly93d3cuZW1hLm9yZy92cGltIA0KICAgICAgIA0KICAgICAgIA0KICAg ICAgIA0KICAgICAgIA0KICAgICAgIA0KICAgICAgDQogICAgIFBhcnNvbnMgICAgICAgICAgICAg ICAgICAgIEV4cGlyZXMgMTAvMDkvMDAgICAgICAgICAgICAgIFtQYWdlIDFdIA0KDCAgICAgIA0K DQogICAgIEludGVybmV0IERyYWZ0ICAgICAgICAgICAgIFZQSU0gQWRkcmVzc2luZyAgICAgICAg ICBNYXJjaCAxMCwgMjAwMCANCiAgICAgIA0KICAgICAgVGFibGUgb2YgQ29udGVudHMgDQogICAg ICAgDQogICAgICAxLiBBYnN0cmFjdCANCiAgICAgIDIuIEludHJvZHVjdGlvbiAgDQogICAgICAz LiBWUElNIHYyIEFkZHJlc3NpbmcgDQogICAgICA0LiBWUElNIHYzIEFkZHJlc3NpbmcgDQogICAg ICAgICAgNC4xIFZQSU0gdjMgU3VibWlzc2lvbiBMSFMgDQogICAgICAgICAgICAgICAgNC4xLjEg VGhlIFZQSU0gQWRkcmVzcyANCiAgICAgICAgICAgICAgICA0LjEuMiBUaGUgVm9pY2UgQWRkcmVz cyANCiAgICAgICAgICAgICAgICA0LjEuMyBUaGUgQU1JUyBBZGRyZXNzIA0KICAgICAgICAgICAg ICAgIDQuMS40IFRoZSBGYXggQWRkcmVzcyANCiAgICAgICAgICA0LjIgVlBJTSB2MyBTdWJtaXNz aW9uIEFkZHJlc3NlcyANCiAgICAgICAgICAgICAgICA0LjIuMSBUaGUgdnBpbS1lbWFpbCANCiAg ICAgICAgICAgICAgICA0LjIuMiBUaGUgdm9pY2UtZW1haWwgDQogICAgICAgICAgICAgICAgNC4y LjMgVGhlIGFtaXMtZW1haWwgDQogICAgICAgICAgICAgICAgNC4yLjQgVGhlIGZheC1lbWFpbCAN CiAgICAgIDUuIFJlZmVyZW5jZXMgDQogICAgICA2LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAN CiAgICAgIDcuIEF1dGhvcidzIEFkZHJlc3MgDQogICAgICA4LiBGdWxsIENvcHlyaWdodCBTdGF0 ZW1lbnQgDQogICAgICA5LiBBcHBlbmRpeCBBOiBJQU5BIFJlZ2lzdHJhdGlvbiBmb3JtIGZvciBu ZXcgdmFsdWUgb2YgR1NUTiAgDQogICAgICAgICAgICAgICAgYWRkcmVzcyBzZXJ2aWNlLXNlbGVj dG9yICJWUElNIiANCiAgICAgIDEwLiBBcHBlbmRpeCBBOiBJQU5BIFJlZ2lzdHJhdGlvbiBmb3Jt IGZvciBuZXcgdmFsdWUgb2YgR1NUTiAgDQogICAgICAgICAgICAgICAgYWRkcmVzcyBzZXJ2aWNl LXNlbGVjdG9yICJWT0lDRSIgDQogICAgICAxMS4gQXBwZW5kaXggQTogSUFOQSBSZWdpc3RyYXRp b24gZm9ybSBmb3IgbmV3IHZhbHVlIG9mIEdTVE4gIA0KICAgICAgICAgICAgICAgIGFkZHJlc3Mg c2VydmljZS1zZWxlY3RvciAiQU1JUyIgDQogICAgICAxMi4gQXBwZW5kaXggRDogSUFOQSBSZWdp c3RyYXRpb24gZm9ybSBmb3IgbmV3IHZhbHVlIG9mIEdTVE4gIA0KICAgICAgICAgICAgICAgIGFk ZHJlc3MgcXVhbGl0LXR5cGUxIGtleXdvcmQgYW5kIHZhbHVlICJTWVNOVU0iIA0KICAgICAgIA0K ICAgICAgIA0KICAgICAgIA0KICAgICAgMS4gIEFic3RyYWN0IA0KICAgICAgIA0KICAgICAgVGhp cyBkb2N1bWVudCBsaXN0cyB0aGUgdmFyaW91cyBWUElNIGVtYWlsIGFkZHJlc3NlcyB0aGF0IGFy ZSANCiAgICAgIGN1cnJlbnRseSBpbiBjb21tb24gdXNlIGFuZCBkZWZpbmVzIHNldmVyYWwgbmV3 IGFkZHJlc3MgZm9ybWF0cyBmb3IgDQogICAgICBzcGVjaWFsIGNhc2UgdXNhZ2UuIA0KICAgICAg IA0KICAgICAgIA0KICAgICAgMi4gIEludHJvZHVjdGlvbiANCiAgICAgICANCiAgICAgIFtWUElN Ml0gZG9lcyBub3QgcGxhY2UgYW55IHJlc3RyaWN0aW9ucyBvbiB0aGUgZW1haWwgYWRkcmVzcyBm b3JtYXQuICANCiAgICAgIEhvd2V2ZXIsIGl0IGRvZXMgc3VnZ2VzdCB0byB1c2UgYSBudW1lcmlj IExIUyBzaW5jZSBtYW55IGxlZ2FjeSANCiAgICAgIHZvaWNlIG1haWwgc3lzdGVtcyBvbmx5IHVz ZSBkaWdpdHMgdG8gaWRlbnRpZnkgbWFpbGJveGVzLiAgRnVydGhlciwgDQogICAgICBpdCBzdWdn ZXN0cyBhIHN0cnVjdHVyZSB0byBoYW5kbGUgcHJpdmF0ZSwgaW50ZXJuYXRpb25hbCBhbmQgDQog ICAgICBleHRlbnNpb25zLiAgVGhlIHByaXZhdGUgZm9ybWF0IGhhcyBiZWNvbWUgZGVwbG95ZWQg aW4gbW9zdCBleGlzdGluZyANCiAgICAgIFZQSU0gdjIgc3lzdGVtcywgZnVydGhlciBzb21lIHN5 c3RlbXMgd2lsbCBvbmx5IGFjY2VwdCBtZXNzYWdlcyBmcm9tIA0KICAgICAgYWRkcmVzc2VzIHdp dGggYSBudW1lcmljIExIUy4gDQogICAgICAgDQogICAgICBbVlBJTTNdIGRvZXMgbm90IGRlc2Ny aWJlIGFkZHJlc3NpbmcgYXQgYWxsLiAgVGhlIExIUyBmb3JtYXQgaXMgDQogICAgICBsZWZ0IHRv IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBtYWlsYm94IG93bmVyLiAgSG93ZXZlciwgaXQgaXMgDQog ICAgICB1c2VmdWwgaW4gc29tZSBjYXNlcyAobGlrZSBzdWJtaXNzaW9uIG9yIHR1bm5lbGluZykg dG8gc3BlY2lmeSBhIA0KDQogICAgICANCiAgICAgUGFyc29ucyAgICAgICAgICAgICAgICAgICBF eHBpcmVzIDEwLzA5LzAwICAgICAgICAgICAgICAgW1BhZ2UgMl0gDQoMICAgICAgDQoNCiAgICAg SW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgVlBJTSBBZGRyZXNzaW5nICAgICAgICAgIE1hcmNo IDEwLCAyMDAwIA0KICAgICAgDQogICAgICBMSFMgZm9ybWF0LiAgQSBmb3JtYXQgYmFzZWQgb24g R1NUTiBBZGRyZXNzaW5nIFtHU1ROXSBpcyANCiAgICAgIHByZXNlbnRlZC4gDQogICAgICAgDQog ICAgICAgDQogICAgICAzLiBWUElNIHYyIEFkZHJlc3NpbmcgDQogICAgICAgIA0KICAgICAgUkZD IDgyMiBhZGRyZXNzZXMgYXJlIGJhc2VkIG9uIHRoZSBkb21haW4gbmFtZSBzeXN0ZW0uICBUaGlz IA0KICAgICAgbmFtaW5nIHN5c3RlbSBoYXMgdHdvIGNvbXBvbmVudHM6IHRoZSBsb2NhbCBwYXJ0 LCB1c2VkIGZvciANCiAgICAgIHVzZXJuYW1lIG9yIG1haWxib3ggaWRlbnRpZmljYXRpb247IGFu ZCB0aGUgaG9zdCBwYXJ0LCB1c2VkIGZvciANCiAgICAgIGdsb2JhbCBtYWNoaW5lIGlkZW50aWZp Y2F0aW9uLiANCiAgICAgIFRoZSBsb2NhbCBwYXJ0IG9mIHRoZSBlbWFpbCBhZGRyZXNzIHNoYWxs IGJlIGEgVVMtQVNDSUkgc3RyaW5nIA0KICAgICAgdW5pcXVlbHkgaWRlbnRpZnlpbmcgYSBtYWls Ym94IG9uIGEgZGVzdGluYXRpb24gc3lzdGVtLiAgRm9yIA0KICAgICAgdm9pY2UgbWVzc2FnaW5n LCB0aGUgbG9jYWwgcGFydCBpcyBhIHByaW50YWJsZSBzdHJpbmcgY29udGFpbmluZyANCiAgICAg IHRoZSBtYWlsYm94IElEIG9mIHRoZSBvcmlnaW5hdG9yIG9yIHJlY2lwaWVudC4gIFdoaWxlIGFs cGhhIA0KICAgICAgY2hhcmFjdGVycyBhbmQgbG9uZyBtYWlsYm94IGlkZW50aWZpZXJzIGFyZSBw ZXJtaXR0ZWQsIG1vc3Qgdm9pY2UgDQogICAgICBtYWlsIG5ldHdvcmtzIHJlbHkgb24gbnVtZXJp YyBtYWlsYm94IGlkZW50aWZpZXJzIHRvIHJldGFpbiANCiAgICAgIGNvbXBhdGliaWxpdHkgd2l0 aCB0aGUgbGltaXRlZCAxMCBkaWdpdCB0ZWxlcGhvbmUga2V5cGFkLiAgQXMgYSANCiAgICAgIHJl c3VsdCwgbWFueSB2b2ljZSBtZXNzYWdpbmcgc3lzdGVtcyBtYXkgb25seSBiZSBhYmxlIHRvIGhh bmRsZSBhIA0KICAgICAgbnVtZXJpYyBsb2NhbCBwYXJ0LiAgVGhlIHJlY2VwdGlvbiBvZiBhbHBo YW51bWVyaWMgbG9jYWwgcGFydHMgb24gDQogICAgICB0aGVzZSBzeXN0ZW1zIG1heSByZXN1bHQg aW46ICB0aGUgYWRkcmVzcyBiZWluZyBtYXBwZWQgdG8gc29tZSANCiAgICAgIGxvY2FsbHkgdW5p cXVlIChidXQgY29uZnVzaW5nIHRvIHRoZSByZWNpcGllbnQpIG51bWJlciwgdGhlIA0KICAgICAg YWRkcmVzcyBiZWluZyBkZWxldGVkIChidXQgc3RpbGwgZGVsaXZlcmVkKSwgb3IgaW4gdGhlIHdv cnN0IGNhc2UgDQogICAgICB0aGUgZW50aXJlIG1lc3NhZ2UgYmVpbmcgcmVqZWN0ZWQuICBBZGRp dGlvbmFsbHksIGl0IG1heSBiZSANCiAgICAgIGRpZmZpY3VsdCB0byBjcmVhdGUgbWVzc2FnZXMg b24gdGhlc2Ugc3lzdGVtcyB3aXRoIGFuIA0KICAgICAgYWxwaGFudW1lcmljIGxvY2FsIHBhcnQg d2l0aG91dCBjb21wbGV4IGtleSBzZXF1ZW5jZXMgb3Igc29tZSANCiAgICAgIGZvcm0gb2YgZGly ZWN0b3J5IGxvb2t1cC4gDQogICAgICAgIA0KICAgICAgSW4gdGhlIGFic2VuY2Ugb2YgYSBnbG9i YWwgZGlyZWN0b3J5LCBzcGVjaWZpY2F0aW9uIG9mIHRoZSBsb2NhbCANCiAgICAgIHBhcnQgaXMg ZXhwZWN0ZWQgdG8gY29uZm9ybSB0byBpbnRlcm5hdGlvbmFsIG9yIHByaXZhdGUgdGVsZXBob25l IA0KICAgICAgbnVtYmVyaW5nIHBsYW5zLiAgSXQgaXMgbGlrZWx5IHRoYXQgcHJpdmF0ZSBudW1i ZXJpbmcgcGxhbnMgd2lsbCANCiAgICAgIHByZXZhaWwgYW5kIHRoZXNlIGFyZSBsZWZ0IGZvciBs b2NhbCBkZWZpbml0aW9uLiAgSG93ZXZlciwgaXQgaXMgDQogICAgICByZWNvbW1lbmRlZCB0aGF0 IHB1YmxpYyB0ZWxlcGhvbmUgbnVtYmVycyBiZSBub3RlZCBhY2NvcmRpbmcgdG8gDQogICAgICB0 aGUgaW50ZXJuYXRpb25hbCBudW1iZXJpbmcgcGxhbiBkZXNjcmliZWQgaW4gW0UuMTY0XS4gVGhl IA0KICAgICAgaW5kaWNhdGlvbiB0aGF0IHRoZSBsb2NhbCBwYXJ0IGlzIGEgcHVibGljIHRlbGVw aG9uZSBudW1iZXIgaXMgDQogICAgICBnaXZlbiBieSBhIHByZWNlZGluZyBgKycgKHRoZSBgKycg d291bGQgbm90IGJlIGVudGVyZWQgZnJvbSBhIA0KICAgICAgdGVsZXBob25lIGtleXBhZCwgaXQg aXMgYWRkZWQgYnkgdGhlIHN5c3RlbSBhcyBhIGZsYWcpLiAgU2luY2UgDQogICAgICB0aGUgcHJp bWFyeSBpbmZvcm1hdGlvbiBpbiB0aGUgbnVtZXJpYyBzY2hlbWUgaXMgY29udGFpbmVkIGJ5IHRo ZSANCiAgICAgIGRpZ2l0cywgb3RoZXIgY2hhcmFjdGVyIHNlcGFyYXRvcnMgKGUuZy4gYC0nKSBt YXkgYmUgaWdub3JlZCANCiAgICAgIChpLmUuIHRvIGFsbG93IHBhcnNpbmcgb2YgdGhlIG51bWVy aWMgbG9jYWwgbWFpbGJveCkgb3IgbWF5IGJlIA0KICAgICAgdXNlZCB0byByZWNvZ25pemUgZGlz dGluY3QgcG9ydGlvbnMgb2YgdGhlIHRlbGVwaG9uZSBudW1iZXIgKGUuZy4gDQogICAgICBjb3Vu dHJ5IGNvZGUpLiAgVGhlIHNwZWNpZmljYXRpb24gb2YgdGhlIGxvY2FsIHBhcnQgb2YgYSBWUElN IA0KICAgICAgYWRkcmVzcyBjYW4gYmUgc3BsaXQgaW50byB0aGUgZm91ciBncm91cHMgZGVzY3Jp YmVkIGJlbG93OiANCiAgICAgICANCiAgICAgIDEpIG1haWxib3ggbnVtYmVyIA0KICAgICAgICAg LSBmb3IgdXNlIGFzIGEgcHJpdmF0ZSBudW1iZXJpbmcgcGxhbiAoYW55IG51bWJlciBvZiBkaWdp dHMpIA0KICAgICAgICAgLSBlLmcuICAyNzIyQGx1Y2VudC5jb20gDQogICAgICAyKSBtYWlsYm94 IG51bWJlcitleHRlbnNpb24gDQogICAgICAgICAtIGZvciB1c2UgYXMgYSBwcml2YXRlIG51bWJl cmluZyBwbGFuIHdpdGggZXh0ZW5zaW9ucyANCiAgICAgICAgICAgYW55IG51bWJlciBvZiBkaWdp dHMsIHVzZSBvZiBgKycgYXMgc2VwYXJhdG9yIA0KICAgICAgICAgLSBlLmcuICAyNzIyKzExMUBs dWNlbnQuY29tIA0KICAgICAgMykgK2ludGVybmF0aW9uYWwgbnVtYmVyIA0KICAgICAgICAgLSBm b3IgaW50ZXJuYXRpb25hbCB0ZWxlcGhvbmUgbnVtYmVycyBjb25mb3JtaW5nIHRvIEUuMTY0IA0K ICAgICAgDQogICAgIFBhcnNvbnMgICAgICAgICAgICAgICAgICAgRXhwaXJlcyAxMC8wOS8wMCAg ICAgICAgICAgICAgIFtQYWdlIDNdIA0KDCAgICAgIA0KDQogICAgIEludGVybmV0IERyYWZ0ICAg ICAgICAgICAgIFZQSU0gQWRkcmVzc2luZyAgICAgICAgICBNYXJjaCAxMCwgMjAwMCANCiAgICAg IA0KICAgICAgICAgICBtYXhpbXVtIG9mIDE1IGRpZ2l0cyANCiAgICAgICAgIC0gZS5nLiAgKzE2 MTM3NjM3NTgyQG5vcnRlbG5ldHdvcmtzLmNvbSANCiAgICAgIDQpICtpbnRlcm5hdGlvbmFsIG51 bWJlcitleHRlbnNpb24gDQogICAgICAgICAtIGZvciBpbnRlcm5hdGlvbmFsIHRlbGVwaG9uZSBu dW1iZXJzIGNvbmZvcm1pbmcgdG8gRS4xNjQgDQogICAgICAgICAgIG1heGltdW0gb2YgMTUgZGln aXRzLCB3aXRoIGFuIGV4dGVuc2lvbiAoZS5nLiBiZWhpbmQgYSANCiAgICAgICAgICAgUEJYKSB0 aGF0IGhhcyBhIG1heGltdW0gb2YgMTUgZGlnaXRzLiAgDQogICAgICAgICAtIGUuZy4gICsxNzAz NTI0NTU1MCsyMzBAZW1hLm9yZyANCiAgICAgICANCiAgICAgIERlcGxveWVkIFZQSU0gdjIgc3lz dGVtcyB0eXBpY2FsbHkgc3VwcG9ydCB0aGUgZmlyc3QgZ3JvdXAsIHRoYXQgaXMgDQogICAgICBt YWlsYm94IG51bWJlciBvbiB0aGUgTEhTLiAgTm90ZSB0aGF0IGluIG1hbnkgY2FzZSB0aGUgbWFp bGJveCBpcyANCiAgICAgIHNpbXBseSB0aGUgbG9jYWwgbnVtYmVyIChlLmcuLCBpbiBOb3J0aCBB bWVyaWNhIHRoZSAxMC1kaWdpdCBOQU5QIA0KICAgICAgbnVtYmVyIGlzIHVzZWQpLiANCiAgICAg ICANCiAgICAgICANCiAgICAgIDQuICBWUElNIHYzIEFkZHJlc3NpbmcgIA0KICAgICAgIA0KICAg ICAgVlBJTSBWZXJzaW9uIDMgcGxhY2VzIG5vIHJlc3RyaWN0aW9ucyBvbiB0aGUgZm9ybSBvZiB0 aGUgSW50ZXJuZXQgDQogICAgICBhZGRyZXNzLiBWUElNIFZlcnNpb24gMyBzeXN0ZW1zIG11c3Qg YmUgY2FwYWJsZSBvZiByZWNlaXZpbmcgYW4gDQogICAgICBhcmJpdHJhcnkgZW1haWwgYWRkcmVz cyBhbmQgZ2VuZXJhdGluZyBhIHJlcGx5IHRvIHRoYXQgYWRkcmVzcy4gIE5vIA0KICAgICAgaW5m ZXJlbmNlcyBhYm91dCB0aGUgc3RydWN0dXJlIG9mIHRoZSBsb2NhbCBwYXJ0IChMSFMpIHNob3Vs ZCBiZSANCiAgICAgIG5lY2Vzc2FyeS4gDQogICAgICAgDQogICAgICBSZWNpcGllbnRzIGVtYWls IGFkZHJlc3NlcyBtdXN0IGJlIGNyZWF0ZWQgaW4gYSBmb3JtIGNvbXBhdGlibGUgd2l0aCANCiAg ICAgIHRoZSByZWNpcGllbnRzIHN5c3RlbSBhbmQgY29uc2lzdGVudCB3aXRoIHRoZSBhZGRyZXNz IGVudHJ5IA0KICAgICAgY2FwYWJpbGl0aWVzIG9mIGEgdGVsZXBob25lIHVzZXIgaW50ZXJmYWNl LiANCiAgICAgICANCiAgICAgICANCiAgICAgIDQuMS4xICBWUElNIHYzIFN1Ym1pc3Npb24gTEhT ICANCiAgICAgICANCiAgICAgIExpbWl0ZWQgY2FwYWJpbGl0eSB2b2ljZSBtYWlsIG1hY2hpbmVz IG1heSBzZW5kIG1lc3NhZ2VzIGJ5IGRlZmF1bHQgDQogICAgICB0byBhbiBleHRlcm5hbCBtZXNz YWdlIHN1Ym1pc3Npb24gZ2F0ZXdheS4gIFRoZXNlIGdhdGV3YXlzIHdpbGwgDQogICAgICBjb252 ZXJ0IHRoZSB1bnJlc29sdmVkIHRlbGVwaG9uZSBudW1iZXIgb2YgdGhlIHJlY2lwaWVudCBpbnRv IGEgDQogICAgICBsZWdpdGltYXRlIGVtYWlsIGFkZHJlc3MuICBNZXNzYWdlcyByZXF1aXJpbmcg YWRkcmVzcyByZXNvbHV0aW9uIA0KICAgICAgbXVzdCBiZSBzZW50IHRvIGEgc3VibWlzc2lvbiBz eXN0ZW0gd2hpY2ggd2lsbCBjb252ZXJ0IHRoZSBzdWJtaXR0ZWQgDQogICAgICBhZGRyZXNzIGlu dG8gdGhlIHJvdXRlLWFibGUgZW1haWwgYWRkcmVzcy4gIA0KICAgICAgIA0KICAgICAgQWRkaXRp b25hbGx5LCBsaW1pdGVkIGNhcGFiaWxpdHkgZW1haWwgc3lzdGVtcyBtYXkgc2VuZCBtZXNzYWdl cyB0byANCiAgICAgIGEgVlBJTSBvbnJhbXAgc3lzdGVtIGluZGljYXRlZCBvbiB0aGUgUkhTLiBU aGUgTEhTIHdvdWxkIGluZGljYXRlIA0KICAgICAgdGhhdCB0aGUgbWVzc2FnZSBpcyB0byBiZSBz ZW50IGFzIGEgVlBJTSBtZXNzYWdlIHRvIHRoZSB0ZWxlcGhvbmUgDQogICAgICBudW1iZXIgaW5k aWNhdGVkLiBJbiB0aGlzIGNhc2UsIGFkZHJlc3MgYW5kIG1lc3NhZ2UgdHJhbnNsYXRpb24gaXMg DQogICAgICBwZXJmb3JtZWQgYnkgdGhlIGdhdGV3YXkuIA0KICAgICAgIA0KICAgICAgVGVsZXBo b25lIG51bWJlcnMgc2VudCBpbiBhIFZQSU0gVmVyc2lvbiAzIHN1Ym1pc3Npb24gbW9kZSBNVVNU IGJlIA0KICAgICAgc2VudCBpbiBvbmUgb2YgdGhlIGZvbGxvd2luZyBmb3Jtcy4gDQogICAgICAg DQogICAgICBUaGlzIGlzIGJhc2VkIG9uIHRoZSBmb3JtYXQgZGVmaW5lZCBpbiBbUFNUTi1BRERS XS4gDQogICAgICAgDQogICAgICBUaGUgVlBJTSBhZGRyZXNzIA0KICAgICAgRm9yIHZvaWNlIG1l c3NhZ2VzIHRoYXQgYXJlIGludGVuZGVkIHRvIGJlIHNlbnQgYXMgVlBJTSBtZXNzYWdlcyB0aGUg DQogICAgICBzZXJ2aWNlLXNlbGVjdG9yIGVsZW1lbnQgaXMgZGVmaW5lZCB0byBiZSAgDQogICAg ICAgDQogICAgICAgICAgICB2cGltLXNlcnZpY2Utc2VsZWN0b3IgPSAiVlBJTSIgDQogICAgICAN CiAgICAgUGFyc29ucyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIDEwLzA5LzAwICAgICAgICAg ICAgICAgW1BhZ2UgNF0gDQoMICAgICAgDQoNCiAgICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAg ICAgVlBJTSBBZGRyZXNzaW5nICAgICAgICAgIE1hcmNoIDEwLCAyMDAwIA0KICAgICAgDQogICAg ICAgDQogICAgICAgICBUaGUgcmVzdWx0YW50IHZwaW0tYWRkcmVzcyBhbmQgdnBpbS1tYm94IGFy ZSBmb3JtYWxseSANCiAgICAgICANCiAgICAgICAgICAgIHZwaW0tYWRkcmVzcyA9IHZwaW0tbWJv eCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgWyBwc3RuLXJlY2lwaWVudCBdIA0KICAgICAg IA0KICAgICAgICAgICAgdnBpbS1tYm94ID0gWyAiVlBJTT0iIF0gKCBnbG9iYWwtcGhvbmUgLyBs b2NhbC1waG9uZSApIA0KICAgICAgICAgICAgICAgICAgICAgICAgWyBzdWItYWRkci1zcGVjICBl eHQtYWRkci1zcGVjIF0gDQogICAgICAgDQogICAgICAgICAgICBleHQtYWRkci1zcGVjID0gWyBl eHQtc2VwIHN1Yi1hZGRyIF0gDQogICAgICAgICAgICBleHQtc2VwID0gKCAiL0VYVD0iIC8gIisi ICkgDQogICAgICAgICAgICAgICAgICAgICAgOyBub3RlIHRoYXQgIi9FWFQ9IiBpcyBjYXNlIElO U0VOU0lUSVZFIA0KICAgICAgICAgICAgICAgICAgICAgIDsgIisiIGlzIHVzZWQgZm9yIGNvbXBh dGliaWxpdHkgd2l0aCBjdXJyZW50IA0KICAgICAgICAgICAgICAgICAgICAgIDsgVlBJTSBhZGRy ZXNzaW5nIA0KICAgICAgIA0KICAgICAgICAgRm9yIGNsYXJpdHksIGhlcmUgaXMgYW4gZXhhbXBs ZSBvZiBhIHZlcnkgc2ltcGxlIHZwaW0tbWJveDogDQogICAgICAgDQogICAgICAgICAgICBWUElN PTYxMzc2Mzc1ODIgDQogICAgICAgDQogICAgICAgDQogICAgICA0LjEuMiAgVGhlIFZvaWNlIGFk ZHJlc3MgDQogICAgICAgDQogICAgICBGb3Igdm9pY2UgbWVzc2FnZXMgdGhhdCBhcmUgaW50ZW5k ZWQgdG8gYmUgc2VudCBhcyBhIHZvaWNlIA0KICAgICAgb3V0ZGlhbGluZyBhdCB0aGUgZGVzdGlu YXRpb24gc3lzdGVtLCB0aGUgc2VydmljZS1zZWxlY3RvciBlbGVtZW50IA0KICAgICAgaXMgZGVm aW5lZCB0byBiZSAgDQogICAgICAgDQogICAgICAgICAgICB2b2ljZS1zZXJ2aWNlLXNlbGVjdG9y ID0gIlZPSUNFIiANCiAgICAgICANCiAgICAgICAgIFRoZSByZXN1bHRhbnQgdm9pY2UtYWRkcmVz cyBhbmQgdm9pY2UtbWJveCBhcmUgZm9ybWFsbHkgDQogICAgICAgDQogICAgICAgICAgICB2b2lj ZS1hZGRyZXNzID0gdm9pY2UtbWJveCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgWyBwc3Ru LXJlY2lwaWVudCBdIA0KICAgICAgIA0KICAgICAgICAgICAgdm9pY2UtbWJveCA9ICJWT0lDRT0i ICggZ2xvYmFsLXBob25lIC8gbG9jYWwtcGhvbmUgKSANCiAgICAgICAgICAgICAgICAgICAgICAg WyBzdWItYWRkciBzcGVjIF0gW3Bvc3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC0gICAgICAgICAgICAtc2VwIHBvc3QtZGlhbF0gDQogICAgICAgDQogICAgICAgICBGb3IgbW9y ZSBjbGFyaXR5LCBoZXJlIGlzIGFuIGV4YW1wbGUgb2YgYSB2ZXJ5IHNpbXBsZSB2b2ljZS1tYm94 OiANCiAgICAgICANCiAgICAgICAgICAgIFZPSUNFPSszOTQwMjI2MzM4IA0KICAgICAgIA0KICAg ICAgIA0KICAgICAgNC4xLjMgIFRoZSBBTUlTIGFkZHJlc3MgDQogICAgICAgDQogICAgICBGb3Ig dm9pY2UgbWVzc2FnZXMgdGhhdCBhcmUgaW50ZW5kZWQgdG8gYmUgc2VudCBhcyBBTUlTIChBdWRp byANCiAgICAgIE1lc3NhZ2luZyBJbnRlcmNoYW5nZSBTcGVjaWZpY2F0aW9uKSB2b2ljZSBtYWls IG1lc3NhZ2VzLCB0aGUgDQogICAgICBzZXJ2aWNlLXNlbGVjdG9yIGVsZW1lbnQgaXMgZGVmaW5l ZCB0byBiZSAgDQogICAgICAgDQogICAgICAgICAgICBhbWlzLXNlcnZpY2Utc2VsZWN0b3IgPSAi QU1JUyIgDQogICAgICAgDQogICAgICAgICBUaGUgcmVzdWx0YW50IGFtaXMtYWRkcmVzcyBhbmQg YW1pcy1tYm94IGFyZSBmb3JtYWxseSANCiAgICAgICANCiAgICAgICAgICAgIGFtaXMtYWRkcmVz cyA9IGFtaXMtbWJveCANCiAgICAgIA0KICAgICBQYXJzb25zICAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgMTAvMDkvMDAgICAgICAgICAgICAgICBbUGFnZSA1XSANCgwgICAgICANCg0KICAgICBJ bnRlcm5ldCBEcmFmdCAgICAgICAgICAgICBWUElNIEFkZHJlc3NpbmcgICAgICAgICAgTWFyY2gg MTAsIDIwMDAgDQogICAgICANCiAgICAgICANCiAgICAgICAgICAgIGFtaXMtbWJveCA9ICJBTUlT PSIgYW1pcy1tYWlsYm94ICANCiAgICAgICAgICAgICAgICAgICAgICAgIFsgIi9TWVNOVU09IiBh bWlzLXN5c251bSBdIA0KICAgICAgICAgICAgICAgICAgICAgICAgOyBub3RlIHRoYXQgIi9TWVNO VU09IiBpcyBjYXNlIElOU0VOU0lUSVZFIA0KICAgICAgIA0KICAgICAgICAgICAgYW1pcy1tYWls Ym94ID0gKCBhbWlzLWEgLyBhbWlzLWQgKSANCiAgICAgICANCiAgICAgICAgICAgIGFtaXMtYSA9 IGFtaXMtYS1udW1iZXIgDQogICAgICAgDQogICAgICAgICAgICBhbWlzLWQgPSBbIGFtaXMtbWFp bGJveC1udW1iZXJwbGFuIF1bICIrIiBdIGFtaXMtbWFpbGJveC1pZCAgDQogICAgICAgICAgICAg ICAgICAgICAgICBbICIrIiBdIFsgYW1pcy1tYWlsYm94LWV4dGVuc2lvbiBdIA0KICAgICAgICAg ICAgICAgICAgICAgICAgOyBUaGUgIisiIHNlcGFyYXRvcnMgYXJlIHVzZWQgdG8gYmUgY29tcGF0 aWJsZSAgDQogICAgICAgICAgICAgICAgICAgICAgICA7IHRoZSBYLjQwMCBBTUlTLUQgbWFpbGJv eCBkZWZpbml0aW9uIC0tICANCiAgICAgICAgICAgICAgICAgICAgICAgIDsgaWYgbW9yZSB0aGFu IG9uZSBlbGVtZW50IGlzIHByZXNlbnQsIGJvdGggDQogICAgICAgICAgICAgICAgICAgICAgICA7 ICIrIiBtdXN0IGFwcGVhci4gIE5vdGUgYWxzbyB0aGF0IHRoZSB0b3RhbCANCiAgICAgICAgICAg ICAgICAgICAgICAgIDsgbGVuZ3RoIG9mIHRoaXMgZmllbGQgaXMgcmVzdHJpY3RlZCB0byAzMiAN CiAgICAgICAgICAgICAgICAgICAgICAgIDsgY2hhcmFjdGVycyBieSBBTUlTLUQuIA0KICAgICAg IA0KICAgICAgICAgICAgYW1pcy1tYWlsYm94LW51bWJlcnBsYW4gPSAxKlZDSEFSIA0KICAgICAg IA0KICAgICAgICAgICAgYW1pcy1tYWlsYm94LWlkID0gMSoxNihWQ0hBUikgDQogICAgICAgDQog ICAgICAgICAgICBhbWlzLW1haWxib3gtZXh0ZW5zaW9uID0gMSpWQ0hBUiANCiAgICAgICANCiAg ICAgICAgICAgIGFtaXMtc3lzbnVtID0gIGFtaXMtYS1udW1iZXIgDQogICAgICAgDQogICAgICAg ICAgICBhbWlzLWEtbnVtYmVyID0gKCBhbWlzLVBTVE4tbnVtYmVyIC8gYW1pcy1wcml2YXRlLW51 bWJlciApIA0KICAgICAgIA0KICAgICAgICAgICAgYW1pcy1QU1ROLW51bWJlciA9IGludC1jb3Vu dHJ5LWNvZGUgIisiIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFyZWEtY29kZSAi KyIgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9jYWwtbnVtYmVyICIrIiANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7IFRoaXMgaXMgaW4gYWdyZWVtZW50IHdpdGgg SVRVIEUuMTY0IFsxMl0gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOyBzcGVjaWZp Y2F0aW9uIGFuZCBwZXIgW0FNSVNBXSAtIHRoZSAgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgOyBtYXhpbXVtIGxlbmd0aCBpcyAxNSBudW1lcmljIGRpZ2l0cy4gIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDsgVGhlICIrIiBzZXBhcmF0b3JzIGFyZSB1c2VkIHRvIGJl ICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7IGNvbXBhdGlibGUgd2l0aCB0aGUg WC40MDAgQU1JUy1EICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7IG1haWxib3gg ZGVmaW5pdGlvbiBhbmQgcmVwbGFjZSB0aGUgJyMnICANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA7IHNlcGFyYXRvcnMgb2YgQU1JUy1BIA0KICAgICAgIA0KICAgICAgICAgICAgYW1p cy1wcml2YXRlLW51bWJlciA9ICIwKysiIGxvY2FsLW51bWJlciAiKyIgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgOyBbQU1JU0FdIGluZGljYXRlcyB0aGF0IG1heGltdW0gcGVybWl0 dGVkIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDsgbGVuZ3RoIG9mIHRoZSBwcml2 YXRlIG51bWJlciBpcyAxNCAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOyBkaWdp dHMgDQogICAgICAgDQogICAgICAgICAgICBpbnQtY291bnRyeS1jb2RlID0gMSo0KERJR0lUKSAN CiAgICAgICAgICAgICANCiAgICAgICAgICAgIGFyZWEtY29kZSA9IDEqKERJR0lUKSANCiAgICAg ICAgICAgICANCiAgICAgICAgICAgIGxvY2FsLW51bWJlciA9IDEqKERJR0lUKSANCiAgICAgICAN CiAgICAgICANCiAgICAgICANCiAgICAgIA0KICAgICBQYXJzb25zICAgICAgICAgICAgICAgICAg IEV4cGlyZXMgMTAvMDkvMDAgICAgICAgICAgICAgICBbUGFnZSA2XSANCgwgICAgICANCg0KICAg ICBJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICBWUElNIEFkZHJlc3NpbmcgICAgICAgICAgTWFy Y2ggMTAsIDIwMDAgDQogICAgICANCiAgICAgICAgIEZvciBtb3JlIGNsYXJpdHksIGhlcmUgaXMg YW4gZXhhbXBsZSBvZiBhIHNpbXBsZSBBTUlTLUEgYW1pcy0gDQogICAgICAgICBtYm94OiANCiAg ICAgICANCiAgICAgICAgICAgIEFNSVM9KzEvNDAxKzMyNzgxNDQrL1NZU05VTT0xKzQwMSszMjc5 NTQyKyANCiAgICAgICANCiAgICAgICANCiAgICAgIDQuMS40IFRoZSBmYXggYWRkcmVzcyANCiAg ICAgICANCiAgICAgIEFzIGRlZmluZWQgaW4gW0ZBWC1BRERSXSANCiAgICAgICANCiAgICAgICAN CiAgICAgIDQuMiBWUElNIHYzIFN1Ym1pc3Npb24gQWRkcmVzc2VzIA0KICAgICAgICAgIA0KICAg ICAgQmFzZWQgb24gUkZDMjMwMywgdGhlc2UgYXJlIHRoZSByZXN1bHRhbnQgZW1haWwgYWRkcmVz c2VzIGZvciB0aGUgDQogICAgICBMSFMgcHJlc2VudGVkIGFib3ZlLiAgVlBJTSB2MyBzeXN0ZW1z IHRoYXQgc3VwcG9ydCBzdWJtaXNzaW9uIE1VU1QgDQogICAgICBhY2NlcHQsIHRyYW5zbGF0ZSAo aWYgbmVjZXNzYXJ5KSwgYW5kIGZvcndhcmQgbWVzc2FnZXMgc2VudCB0byB0aGVzZSANCiAgICAg IGFkZHJlc3Nlcy4gIA0KICAgICAgICAgICAgDQogICAgICAgDQogICAgICA0LjIuMSBUaGUgdnBp bS1lbWFpbCANCiAgICAgICAgICAgDQogICAgICBUaGUgdnBpbS1lbWFpbCBlbGVtZW50IGlzIGEg c3BlY2lmaWMgdmVyc2lvbiBvZiBwc3RuLWVtYWlsIGZvciBWUElNIA0KICAgICAgb3ZlciB0aGUg SW50ZXJuZXQgZS1tYWlsIHRyYW5zcG9ydCBzeXN0ZW0sIHdoZXJlIHRoZSBzZXJ2aWNlLQ0KICAg ICAgc2VsZWN0b3IgZGlzdGluY3Rpb24gaXMgc2V0IHRvICJWUElNIi4gDQogICAgICAgICAgICAN CiAgICAgICAgICAgICAgICB2cGltLWVtYWlsID0gIFsiLyJdIHZwaW0tYWRkcmVzcyBbIi8iXSAi QCIgbXRhLUktcHN0biANCiAgICAgICAgICAgIA0KICAgICAgSW4gdGhpcyBjYXNlIHRoZSBtdGEt SS1wc3RuIHdpbGwgdXN1YWxseSBwb2ludCB0byBhIFZQSU0gY2FwYWJsZSANCiAgICAgIG1lc3Nh Z2luZyBzeXN0ZW0gd2hlcmUgdGhlIGF0dGFjaGVkIG1lc3NhZ2Ugd2lsbCBiZSBkZWxpdmVyZWQg DQogICAgICBwcm9wZXJseS4gDQogICAgICAgICAgICANCiAgICAgICANCiAgICAgIDQuMi4yIFRo ZSB2b2ljZS1lbWFpbCANCiAgICAgICAgICAgDQogICAgICBUaGUgdm9pY2UtZW1haWwgZWxlbWVu dCBpcyBhIHNwZWNpZmljIHZlcnNpb24gb2YgcHN0bi1lbWFpbCBmb3IgdGhlIA0KICAgICAgdm9p Y2Ugb3V0ZGlhbGluZyBvdmVyIHRoZSBJbnRlcm5ldCBlLW1haWwgdHJhbnNwb3J0IHN5c3RlbSwg d2hlcmUgDQogICAgICB0aGUgc2VydmljZS1zZWxlY3RvciBkaXN0aW5jdGlvbiBpcyBzZXQgdG8g IlZPSUNFIi4gDQogICAgICAgICAgICANCiAgICAgICAgICAgICAgICB2b2ljZS1lbWFpbCA9ICBb Ii8iXSB2b2ljZS1hZGRyZXNzIFsiLyJdICJAIiBtdGEtSS1wc3RuIA0KICAgICAgICAgICAgDQog ICAgICBJbiB0aGlzIGNhc2UgdGhlIG10YS1JLXBzdG4gd2lsbCB1c3VhbGx5IHBvaW50IHRvIGEg ZGV2aWNlIHRoYXQgd2lsbCANCiAgICAgIHBlcmZvcm0gYW4gb3V0ZGlhbCwgdGhhdCBpcyBmb3Ig ZXhhbXBsZSwgbWFrZSBhIHRlbGVwaG9uZSBjYWxsIHRvIA0KICAgICAgdGhlIHNwZWNpZmllZCBu dW1iZXIgYW5kIHBsYXkgYSB2b2ljZSBhdHRhY2htZW50LiANCiAgICAgICAgICAgIA0KICAgICAg IA0KICAgICAgNC4yLjMgVGhlIGFtaXMtZW1haWwgDQogICAgICAgDQogICAgICBUaGUgYW1pcy1l bWFpbCBlbGVtZW50IGlzIGEgc3BlY2lmaWMgdmVyc2lvbiBvZiBwc3RuLWVtYWlsIGZvciB0aGUg DQogICAgICBBTUlTIG92ZXIgdGhlIEludGVybmV0IGUtbWFpbCB0cmFuc3BvcnQgc3lzdGVtLCB3 aGVyZSB0aGUgc2VydmljZS0NCiAgICAgIHNlbGVjdG9yIGRpc3RpbmN0aW9uIGlzIHNldCB0byAi QU1JUyIuIA0KICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgYW1pcy1lbWFpbCA9ICBbIi8i XSBhbWlzLWFkZHJlc3MgWyIvIl0gIkAiIG10YS1JLXBzdG4gDQogICAgICANCiAgICAgUGFyc29u cyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIDEwLzA5LzAwICAgICAgICAgICAgICAgW1BhZ2Ug N10gDQoMICAgICAgDQoNCiAgICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgVlBJTSBBZGRy ZXNzaW5nICAgICAgICAgIE1hcmNoIDEwLCAyMDAwIA0KICAgICAgDQogICAgICAgICAgICANCiAg ICAgIEluIHRoaXMgY2FzZSB0aGUgbXRhLUktcHN0biB3aWxsIHVzdWFsbHkgcG9pbnQgdG8gYSBk ZXZpY2UgdGhhdCBhY3RzIA0KICAgICAgYXMgYSBnYXRld2F5IHRvIGFuIEFNSVMgbmV0d29yayB3 aGVyZSB0aGUgYXR0YWNoZWQgdm9pY2UgbWVzc2FnZSANCiAgICAgIHdpbGwgYmUgZGVsaXZlcmVk IHByb3Blcmx5LiANCiAgICAgICAgICAgIA0KICAgICAgIA0KICAgICAgNC4yLjQgVGhlIGZheC1l bWFpbCANCiAgICAgICAgICAgIA0KICAgICAgQXMgZGVmaW5lZCBpbiBbRkFYLUFERFJdIA0KICAg ICAgIA0KICAgICAgIA0KICAgICAgNS4gUmVmZXJlbmNlcyANCiAgICAgICAgICAgIA0KICAgICAg W0FNSVMtQV0gQXVkaW8gTWVzc2FnaW5nIEludGVyY2hhbmdlIFNwZWNpZmljYXRpb25zIChBTUlT KSAtIEFuYWxvZyANCiAgICAgIFByb3RvY29sIFZlcnNpb24gMSwgSXNzdWUgMiwgRmVicnVhcnkg MTk5Mi4gDQogICAgICAgICAgICANCiAgICAgIFtBTUlTLURdIEF1ZGlvIE1lc3NhZ2luZyBJbnRl cmNoYW5nZSBTcGVjaWZpY2F0aW9ucyAoQU1JUykgLSBEaWdpdGFsIA0KICAgICAgUHJvdG9jb2wg VmVyc2lvbiAxLCBJc3N1ZSAzIEF1Z3VzdCAxOTkzLiANCiAgICAgICAgICAgIA0KICAgICAgW0Ux NjRdIENDSVRUIFJlY29tbWVuZGF0aW9uIEUuMTY0ICgxOTkxKSwgVGVsZXBob25lIE5ldHdvcmsg YW5kIElTRE4gDQogICAgICBPcGVyYXRpb24sIE51bWJlcmluZywgUm91dGluZyBhbmQgIE1vYmls ZSBTZXJ2aWNlIC0gTnVtYmVyaW5nIFBsYW4gDQogICAgICBmb3IgdGhlIElTRE4gRXJhLiAgIA0K ICAgICAgIA0KICAgICAgW0dTVE5dIEFsbG9jY2hpbywgQy4sICJHU1ROIEFkZHJlc3MgRWxlbWVu dCBFeHRlbnNpb25zIGluIGUtbWFpbCANCiAgICAgIFNlcnZpY2VzIiwgPGRyYWZ0LWlldGYtZmF4 LWZ1bGxhZGRyLTA2LnR4dD4sIFdvcmsgSW4gUHJvZ3Jlc3MgDQogICAgICAgICAgICANCiAgICAg IFtSRkM4MjJdIENyb2NrZXIsIEQuLCAiU3RhbmRhcmQgZm9yIHRoZSBGb3JtYXQgb2YgQVJQQSBJ bnRlcm5ldCBUZXh0IA0KICAgICAgTWVzc2FnZXMiLCBTVEQgMTEsIFJGQyA4MjIsIFVERUwsIEF1 Z3VzdCAxOTgyLiANCiAgICAgICAgICAgIA0KICAgICAgW1ZQSU0yXSBWYXVkcmV1aWwsIEdyZWcs IFBhcnNvbnMsIEdsZW5uLCAiVm9pY2UgUHJvZmlsZSBmb3IgSW50ZXJuZXQgDQogICAgICBNYWls LCBWZXJzaW9uIDIiLCBSRkMgMjQyMSwgU2VwdGVtYmVyIDE5OTguIA0KICAgICAgICAgICAgDQog ICAgICBbVlBJTTNdIFZhdWRyZXVpbCwgR3JlZywgUGFyc29ucywgR2xlbm4sICJWb2ljZSBQcm9m aWxlIGZvciBJbnRlcm5ldCANCiAgICAgIE1haWwsIFZlcnNpb24gMyIsIDxkcmFmdC1lbWEtdnBp bXYzLTAwLnR4dD4sIFdvcmsgaW4gcHJvZ3Jlc3MuIA0KICAgICAgICAgICAgDQogICAgICBbRkFY LUFERFJdIEFsbG9jY2hpbywgQy4sICJNaW5pbWFsIEZBWCBhZGRyZXNzIGZvcm1hdCBpbiBJbnRl cm5ldCANCiAgICAgIE1haWwiLCBSRkMgMjMwNCwgTWFyY2ggMTk5OC4gDQogICAgICAgICAgICAN CiAgICAgIFtQU1ROLUFERFJdIEFsbG9jY2hpbywgQy4sICJNaW5pbWFsIFBTVE4gYWRkcmVzcyBm b3JtYXQgaW4gSW50ZXJuZXQgDQogICAgICBNYWlsIiwgUkZDIDIzMDMsIE1hcmNoIDE5OTguIA0K ICAgICAgICAgICAgDQogICAgICAgDQogICAgICA2LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAN CiAgICAgICAgICAgICAgIA0KICAgICAgTm9uZSBiZXlvbmQgdGhvc2UgYWxyZWFkeSBpZGVudGlm aWVkIGluIFtWUElNMl0gYW5kIFtWUElNM10uIA0KICAgICAgICAgICAgDQogICAgICAgDQogICAg ICAgDQogICAgICAgDQogICAgICAgDQogICAgICAgDQogICAgICAgDQogICAgICANCiAgICAgUGFy c29ucyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIDEwLzA5LzAwICAgICAgICAgICAgICAgW1Bh Z2UgOF0gDQoMICAgICAgDQoNCiAgICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgVlBJTSBB ZGRyZXNzaW5nICAgICAgICAgIE1hcmNoIDEwLCAyMDAwIA0KICAgICAgDQogICAgICA3LiBBdXRo b3IncyBBZGRyZXNzIA0KICAgICAgICAgICAgDQogICAgICAgICAgICAgIEdsZW5uIFcuIFBhcnNv bnMgDQogICAgICAgICAgICAgIE5vcnRlbCBOZXR3b3JrcyANCiAgICAgICAgICAgICAgUC5PLiBC b3ggMzUxMSwgU3RhdGlvbiBDIA0KICAgICAgICAgICAgICBPdHRhd2EsIE9OIEsxWSA0SDcgDQog ICAgICAgICAgICAgIFBob25lOiArMS02MTMtNzYzLTc1ODIgDQogICAgICAgICAgICAgIEZheCAg OiArMS02MTMtNzYzLTQ0NjEgDQogICAgICAgICAgICAgIEVtYWlsOiBncGFyc29uc0Bub3J0ZWxu ZXR3b3Jrcy5jb20gDQogICAgICAgICAgICANCiAgICAgICANCiAgICAgIDguIEZ1bGwgQ29weXJp Z2h0IFN0YXRlbWVudCANCiAgICAgICANCiAgICAgICJDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5l dCBTb2NpZXR5ICgyMDAwKS4gIEFsbCBSaWdodHMgUmVzZXJ2ZWQuIA0KICAgICAgIA0KICAgICAg VGhpcyBkb2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQgYW5kIGZ1 cm5pc2hlZCB0byANCiAgICAgIG90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21t ZW50IG9uIG9yIG90aGVyd2lzZSBleHBsYWluIGl0IA0KICAgICAgb3IgYXNzaXN0IGluIGl0cyBp bXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGllZCwgcHVibGlzaGVkIA0KICAgICAg YW5kIGRpc3RyaWJ1dGVkLCBpbiB3aG9sZSBvciBpbiBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9u IG9mIGFueSANCiAgICAgIGtpbmQsIHByb3ZpZGVkIHRoYXQgdGhlIGFib3ZlIGNvcHlyaWdodCBu b3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoIA0KICAgICAgYXJlIGluY2x1ZGVkIG9uIGFsbCBzdWNo IGNvcGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jrcy4gIEhvd2V2ZXIsIHRoaXMgDQogICAgICBkb2N1 bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJl bW92aW5nIA0KICAgICAgdGhlIGNvcHlyaWdodCBub3RpY2Ugb3IgcmVmZXJlbmNlcyB0byB0aGUg SW50ZXJuZXQgU29jaWV0eSBvciBvdGhlciANCiAgICAgIEludGVybmV0IG9yZ2FuaXphdGlvbnMs IGV4Y2VwdCBhcyBuZWVkZWQgZm9yIHRoZSBwdXJwb3NlIG9mIA0KICAgICAgZGV2ZWxvcGluZyBJ bnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IgDQogICAg ICBjb3B5cmlnaHRzIGRlZmluZWQgaW4gdGhlIEludGVybmV0IFN0YW5kYXJkcyBwcm9jZXNzIG11 c3QgYmUgDQogICAgICBmb2xsb3dlZCwgb3IgYXMgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0IGlu dG8gbGFuZ3VhZ2VzIG90aGVyIHRoYW4gDQogICAgICBFbmdsaXNoLiANCiAgICAgICANCiAgICAg IFRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBhbmQg d2lsbCBub3QgYmUgDQogICAgICByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0 cyBzdWNjZXNzb3JzIG9yIGFzc2lnbnMuIA0KICAgICAgIA0KICAgICAgVGhpcyBkb2N1bWVudCBh bmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgcHJvdmlkZWQgb24gDQogICAg ICBhbiAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVS TkVUIA0KICAgICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTVMgQUxMIFdBUlJBTlRJ RVMsIEVYUFJFU1MgT1IgDQogICAgICBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVE IFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgDQogICAgICBPRiBUSEUgSU5GT1JNQVRJT04g SEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIA0KICAgICAgSU1QTElF RCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VM QVIgDQogICAgICBQVVJQT1NFLiIgDQogICAgICAgDQogICAgICAgDQogICAgICAgDQogICAgICAg DQogICAgICAgDQogICAgICAgDQogICAgICAgDQogICAgICAgDQogICAgICAgDQogICAgICAgDQog ICAgICAgDQogICAgICAgDQogICAgICAgDQogICAgICANCiAgICAgUGFyc29ucyAgICAgICAgICAg ICAgICAgICBFeHBpcmVzIDEwLzA5LzAwICAgICAgICAgICAgICAgW1BhZ2UgOV0gDQoMICAgICAg DQoNCiAgICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgVlBJTSBBZGRyZXNzaW5nICAgICAg ICAgIE1hcmNoIDEwLCAyMDAwIA0KICAgICAgDQogICAgICA5LiAgQXBwZW5kaXggQTogSUFOQSBS ZWdpc3RyYXRpb24gZm9ybSBmb3IgbmV3IHZhbHVlIG9mIEdTVE4gIA0KICAgICAgICAgICAgICAg ICAgICAgIGFkZHJlc3Mgc2VydmljZS1zZWxlY3RvciAiVlBJTSIgDQogICAgICAgDQogICAgICAg ICBUbzogSUFOQUBpc2kuZWR1IA0KICAgICAgICANCiAgICAgICAgIFN1YmplY3Q6IFJlZ2lzdHJh dGlvbiBvZiBuZXcgdmFsdWVzIGZvciB0aGUgR1NUTiBhZGRyZXNzICANCiAgICAgICAgICAgICAg ICAgIHNlcnZpY2Utc2VsZWN0b3Igc3BlY2lmaWVyICJWUElNIiANCiAgICAgICAgICAgICAgDQog ICAgICAgICBzZXJ2aWNlLXNlbGVjdG9yIG5hbWU6IA0KICAgICAgIA0KICAgICAgICAgICAgVlBJ TSANCiAgICAgICANCiAgICAgICAgIERlc2NyaXB0aW9uIG9mIFVzZTogDQogICAgICAgDQogICAg ICAgICAgICBWUElNIC0gc3BlY2lmeSB0aGF0IHRoZSBHU1ROIGFkZHJlc3MgcmVmZXJzIHRvIGEg dm9pY2UgDQogICAgICAgICAgICBtYWlsYm94IHRoYXQgaXMgaW50ZW5kZWQgdG8gYWNjZXB0IGEg VlBJTSBtZXNzYWdlLiANCiAgICAgICANCiAgICAgICAgICAgIEZvciBhIGNvbXBsZXRlIGRlc2Ny aXB0aW9uIHJlZmVyIHRvICJWUElNIEFkZHJlc3NpbmciLCANCiAgICAgICAgICAgIGRyYWZ0LWVt YS12cGltLWFkZHJlc3MtMDEudHh0LiANCiAgICAgICANCiAgICAgICAgIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zOiANCiAgICAgICANCiAgICAgICAgICAgIFNlZSB0aGUgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbiBzZWN0aW9uIG9mICJWUElNIA0KICAgICAgICAgICAgQWRkcmVzc2luZyIsIGRyYWZ0 LWVtYS12cGltLWFkZHJlc3MtMDEudHh0LiANCiAgICAgICANCiAgICAgICAgIFBlcnNvbiAmIGVt YWlsIGFkZHJlc3MgdG8gY29udGFjdCBmb3IgZnVydGhlciBpbmZvcm1hdGlvbjogDQogICAgICAg DQogICAgICAgICAgICBHbGVubiBXLiBQYXJzb25zIA0KICAgICAgICAgICAgTm9ydGVsIE5ldHdv cmtzIA0KICAgICAgICAgICAgUC4wLiBCb3ggMzUxMSBTdGF0aW9uIEMgDQogICAgICAgICAgICBP dHRhd2EsIE9uICBLMVkgNEg3IA0KICAgICAgICAgICAgQ2FuYWRhIA0KICAgICAgICAgICAgUGhv bmU6ICsxLTYxMy03NjMtNzU4MiANCiAgICAgICAgICAgIEZheCAgOiArMS02MTMtNDQ2MSANCiAg ICAgICAgICAgIEVtYWlsOiBncGFyc29uc0Bub3J0ZWxuZXR3b3Jrcy5jb20gDQogICAgICAgDQog ICAgICAgICAgIA0KICAgICAgIA0KICAgICAgIA0KICAgICAgIA0KICAgICAgIA0KICAgICAgIA0K ICAgICAgIA0KICAgICAgIA0KICAgICAgIA0KICAgICAgIA0KICAgICAgIA0KICAgICAgIA0KICAg ICAgIA0KICAgICAgIA0KICAgICAgIA0KICAgICAgIA0KICAgICAgDQogICAgIFBhcnNvbnMgICAg ICAgICAgICAgICAgICAgRXhwaXJlcyAxMC8wOS8wMCAgICAgICAgICAgICAgIFtQYWdlIDEwXSAN CgwgICAgICANCg0KICAgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICBWUElNIEFkZHJlc3Np bmcgICAgICAgICAgTWFyY2ggMTAsIDIwMDAgDQogICAgICANCiAgICAgICAgMTAuICBBcHBlbmRp eCBCOiBJQU5BIFJlZ2lzdHJhdGlvbiBmb3JtIGZvciBuZXcgdmFsdWUgb2YgR1NUTiAgDQogICAg ICAgICAgICAgICAgICAgICAgICAgYWRkcmVzcyBzZXJ2aWNlLXNlbGVjdG9yICJWT0lDRSIgDQog ICAgICAgDQogICAgICAgICBUbzogSUFOQUBpc2kuZWR1IA0KICAgICAgICANCiAgICAgICAgIFN1 YmplY3Q6IFJlZ2lzdHJhdGlvbiBvZiBuZXcgdmFsdWVzIGZvciB0aGUgR1NUTiBhZGRyZXNzICAN CiAgICAgICAgICAgICAgICAgIHNlcnZpY2Utc2VsZWN0b3Igc3BlY2lmaWVyICJWT0lDRSIgDQog ICAgICAgICAgICAgIA0KICAgICAgICAgc2VydmljZS1zZWxlY3RvciBuYW1lOiANCiAgICAgICAN CiAgICAgICAgICAgIFZPSUNFIA0KICAgICAgIA0KICAgICAgICAgRGVzY3JpcHRpb24gb2YgVXNl OiANCiAgICAgICANCiAgICAgICAgICAgIFZPSUNFIC0gc3BlY2lmeSB0aGF0IHRoZSBHU1ROIGFk ZHJlc3MgcmVmZXJzIHRvIGEgdm9pY2UgDQogICAgICAgICAgICBkZXZpY2UgdGhhdCBpcyBpbnRl bmRlZCB0byBiZSBzZW50IGEgdm9pY2UgbWVzc2FnZSB2aWEgYW4gDQogICAgICAgICAgICAnb3V0 ZGlhbGluZycuIA0KICAgICAgIA0KICAgICAgICAgICAgRm9yIGEgY29tcGxldGUgZGVzY3JpcHRp b24gcmVmZXIgdG8gIlZQSU0gQWRkcmVzc2luZyIsIA0KICAgICAgICAgICAgZHJhZnQtZW1hLXZw aW0tYWRkcmVzcy0wMS50eHQuIA0KICAgICAgIA0KICAgICAgICAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnM6IA0KICAgICAgIA0KICAgICAgICAgICAgU2VlIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0 aW9uIHNlY3Rpb24gb2YgIlZQSU0gDQogICAgICAgICAgICBBZGRyZXNzaW5nIiwgZHJhZnQtZW1h LXZwaW0tYWRkcmVzcy0wMS50eHQuIA0KICAgICAgIA0KICAgICAgICAgUGVyc29uICYgZW1haWwg YWRkcmVzcyB0byBjb250YWN0IGZvciBmdXJ0aGVyIGluZm9ybWF0aW9uOiANCiAgICAgICANCiAg ICAgICAgICAgIEdsZW5uIFcuIFBhcnNvbnMgDQogICAgICAgICAgICBOb3J0ZWwgTmV0d29ya3Mg DQogICAgICAgICAgICBQLjAuIEJveCAzNTExIFN0YXRpb24gQyANCiAgICAgICAgICAgIE90dGF3 YSwgT24gIEsxWSA0SDcgDQogICAgICAgICAgICBDYW5hZGEgDQogICAgICAgICAgICBQaG9uZTog KzEtNjEzLTc2My03NTgyIA0KICAgICAgICAgICAgRmF4ICA6ICsxLTYxMy00NDYxIA0KICAgICAg ICAgICAgRW1haWw6IGdwYXJzb25zQG5vcnRlbG5ldHdvcmtzLmNvbSANCiAgICAgICAgICANCiAg ICAgICAgICANCiAgICAgICAgICANCiAgICAgICAgICANCiAgICAgICAgICANCiAgICAgICAgICAN CiAgICAgICAgICANCiAgICAgICAgICANCiAgICAgICAgICANCiAgICAgICAgICANCiAgICAgICAg ICANCiAgICAgICAgICANCiAgICAgICAgICANCiAgICAgICAgICANCiAgICAgICAgICANCiAgICAg ICAgICANCiAgICAgIA0KICAgICBQYXJzb25zICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgMTAv MDkvMDAgICAgICAgICAgICAgICBbUGFnZSAxMV0gDQoMICAgICAgDQoNCiAgICAgSW50ZXJuZXQg RHJhZnQgICAgICAgICAgICAgVlBJTSBBZGRyZXNzaW5nICAgICAgICAgIE1hcmNoIDEwLCAyMDAw IA0KICAgICAgDQogICAgICAgIDExLiAgQXBwZW5kaXggQzogSUFOQSBSZWdpc3RyYXRpb24gZm9y bSBmb3IgbmV3IHZhbHVlIG9mIEdTVE4gIA0KICAgICAgICAgICAgICAgICAgICAgICAgIGFkZHJl c3Mgc2VydmljZS1zZWxlY3RvciAiQU1JUyIgDQogICAgICAgDQogICAgICAgICBUbzogSUFOQUBp c2kuZWR1IA0KICAgICAgICANCiAgICAgICAgIFN1YmplY3Q6IFJlZ2lzdHJhdGlvbiBvZiBuZXcg dmFsdWVzIGZvciB0aGUgR1NUTiBhZGRyZXNzICANCiAgICAgICAgICAgICAgICAgIHNlcnZpY2Ut c2VsZWN0b3Igc3BlY2lmaWVyICJBTUlTIiANCiAgICAgICAgICAgICAgDQogICAgICAgICBzZXJ2 aWNlLXNlbGVjdG9yIG5hbWU6IA0KICAgICAgIA0KICAgICAgICAgICAgQU1JUyANCiAgICAgICAN CiAgICAgICAgIERlc2NyaXB0aW9uIG9mIFVzZTogDQogICAgICAgDQogICAgICAgICAgICBBTUlT IC0gc3BlY2lmeSB0aGF0IHRoZSBHU1ROIGFkZHJlc3MgcmVmZXJzIHRvIGEgdm9pY2UgDQogICAg ICAgICAgICBtYWlsYm94IHRoYXQgaXMgaW50ZW5kZWQgdG8gYmUgc2VudCBhbiBBTUlTIChBdWRp byANCiAgICAgICAgICAgIE1lc3NhZ2luZyBJbnRlcmNoYW5nZSBTcGVjaWZpY2F0aW9uKSB2b2lj ZSBtYWlsIG1lc3NhZ2UuIA0KICAgICAgIA0KICAgICAgICAgICAgRm9yIGEgY29tcGxldGUgZGVz Y3JpcHRpb24gcmVmZXIgdG8gIlZQSU0gQWRkcmVzc2luZyIsIA0KICAgICAgICAgICAgZHJhZnQt ZW1hLXZwaW0tYWRkcmVzcy0wMS50eHQuIA0KICAgICAgIA0KICAgICAgICAgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnM6IA0KICAgICAgIA0KICAgICAgICAgICAgU2VlIHRoZSBTZWN1cml0eSBDb25z aWRlcmF0aW9uIHNlY3Rpb24gb2YgIlZQSU0gDQogICAgICAgICAgICBBZGRyZXNzaW5nIiwgZHJh ZnQtZW1hLXZwaW0tYWRkcmVzcy0wMS50eHQuIA0KICAgICAgIA0KICAgICAgICAgUGVyc29uICYg ZW1haWwgYWRkcmVzcyB0byBjb250YWN0IGZvciBmdXJ0aGVyIGluZm9ybWF0aW9uOiANCiAgICAg ICANCiAgICAgICAgICAgIEdsZW5uIFcuIFBhcnNvbnMgDQogICAgICAgICAgICBOb3J0ZWwgTmV0 d29ya3MgDQogICAgICAgICAgICBQLjAuIEJveCAzNTExIFN0YXRpb24gQyANCiAgICAgICAgICAg IE90dGF3YSwgT24gIEsxWSA0SDcgDQogICAgICAgICAgICBDYW5hZGEgDQogICAgICAgICAgICBQ aG9uZTogKzEtNjEzLTc2My03NTgyIA0KICAgICAgICAgICAgRmF4ICA6ICsxLTYxMy00NDYxIA0K ICAgICAgICAgICAgRW1haWw6IGdwYXJzb25zQG5vcnRlbG5ldHdvcmtzLmNvbSANCiAgICAgICAN CiAgICAgICANCiAgICAgICANCiAgICAgICANCiAgICAgICANCiAgICAgICANCiAgICAgICANCiAg ICAgICANCiAgICAgICANCiAgICAgICANCiAgICAgICANCiAgICAgICANCiAgICAgICANCiAgICAg ICANCiAgICAgICANCiAgICAgICANCiAgICAgIA0KICAgICBQYXJzb25zICAgICAgICAgICAgICAg ICAgIEV4cGlyZXMgMTAvMDkvMDAgICAgICAgICAgICAgICBbUGFnZSAxMl0gDQoMICAgICAgDQoN CiAgICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgVlBJTSBBZGRyZXNzaW5nICAgICAgICAg IE1hcmNoIDEwLCAyMDAwIA0KICAgICAgDQogICAgICAxMi4gIEFwcGVuZGl4IEQ6IElBTkEgUmVn aXN0cmF0aW9uIGZvcm0gZm9yIG5ldyB2YWx1ZSBvZiBHU1ROICANCiAgICAgICAgICAgICAgICAg ICAgICAgIGFkZHJlc3MgcXVhbGl0LXR5cGUxIGtleXdvcmQgYW5kIHZhbHVlICJTWVNOVU0iIA0K ICAgICAgIA0KICAgICAgICAgVG86IElBTkFAaXNpLmVkdSAgDQogICAgICAgDQogICAgICAgICBT dWJqZWN0OiBSZWdpc3RyYXRpb24gb2YgbmV3IHZhbHVlcyBmb3IgdGhlIEdTVE4gYWRkcmVzcyAg DQogICAgICAgICAgICAgICAgICBxdWFsaWYtdHlwZTEgZWxlbWVudCAic3lzbnVtIiANCiAgICAg ICAgICAgICAgDQogICAgICAgICBxdWFsaWYtdHlwZTEgImtleXdvcmQiIG5hbWU6IA0KICAgICAg IA0KICAgICAgICAgICAgc3lzbnVtIA0KICAgICAgIA0KICAgICAgICAgcXVhbGlmLXR5cGUxICJ2 YWx1ZSIgQUJORiBkZWZpbml0aW9uOiANCiAgICAgICANCiAgICAgICAgICAgIHN5c251bSA9IDEq KERJR0lUIC8gIisiKSANCiAgICAgICANCiAgICAgICAgIERlc2NyaXB0aW9uIG9mIFVzZTogDQog ICAgICAgDQogICAgICAgICAgICBzeXNudW0gaXMgdXNlZCB0byBzcGVjaWZ5IHRoZSBudW1lcmlj IG9wdGlvbmFsIEFNSVMgc3ViLQ0KICAgICAgICAgICAgYWRkcmVzcyBlbGVtZW50IGFzIGRlc2Ny aWJlZCBpbiAiVlBJTSBBZGRyZXNzaW5nIiwgZHJhZnQtDQogICAgICAgICAgICBlbWEtdnBpbS1h ZGRyZXNzLTAxLnR4dC4gDQogICAgICAgDQogICAgICAgICBVc2UgUmVzdHJpY3Rpb246IA0KICAg ICAgIA0KICAgICAgICAgICAgVGhlIHVzZSBvZiAiU1lTTlVNIiBpcyByZXN0cmljdGVkIHRvICJB TUlTIiBzZXJ2aWNlLQ0KICAgICAgICAgICAgc2VsZWN0b3IsIGlzIGl0IGhhcyBubyBtZWFuaW5n IG91dHNpZGUgdGhlIEFNSVMgc2VydmljZS4gDQogICAgICAgDQogICAgICAgICBTZWN1cml0eSBD b25zaWRlcmF0aW9uczogDQogICAgICAgDQogICAgICAgICAgICBTZWUgdGhlIFNlY3VyaXR5IENv bnNpZGVyYXRpb24gc2VjdGlvbiBvZiAiVlBJTSANCiAgICAgICAgICAgIEFkZHJlc3NpbmciLCBk cmFmdC1lbWEtdnBpbS1hZGRyZXNzLTAxLnR4dC4gDQogICAgICAgDQogICAgICAgICBQZXJzb24g JiBlbWFpbCBhZGRyZXNzIHRvIGNvbnRhY3QgZm9yIGZ1cnRoZXIgaW5mb3JtYXRpb246IA0KICAg ICAgICAgICAgIA0KICAgICAgICAgICAgR2xlbm4gVy4gUGFyc29ucyANCiAgICAgICAgICAgIE5v cnRlbCBOZXR3b3JrcyANCiAgICAgICAgICAgIFAuMC4gQm94IDM1MTEgU3RhdGlvbiBDIA0KICAg ICAgICAgICAgT3R0YXdhLCBPbiAgSzFZIDRINyANCiAgICAgICAgICAgIENhbmFkYSANCiAgICAg ICAgICAgIFBob25lOiArMS02MTMtNzYzLTc1ODIgDQogICAgICAgICAgICBGYXggIDogKzEtNjEz LTQ0NjEgDQogICAgICAgICAgICBFbWFpbDogZ3BhcnNvbnNAbm9ydGVsbmV0d29ya3MuY29tIA0K DQoNCg0KDQoNCg0KDQoNCg0KDQogICAgICANCiAgICAgUGFyc29ucyAgICAgICAgICAgICAgICAg ICBFeHBpcmVzIDEwLzA5LzAwICAgICAgICAgICAgICAgW1BhZ2UgMTNdIA0KDA0K ------_=_NextPart_000_01BF8ADC.EAFEEADA-- From owner-ietf-fax@mail.imc.org Sat Mar 11 20:45:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23140 for ; Sat, 11 Mar 2000 20:45:08 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA06875 for ietf-fax-bks; Sat, 11 Mar 2000 17:09:03 -0800 (PST) Received: from mauve.innosoft.com (mauve.innosoft.com [192.160.253.247]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA06871 for ; Sat, 11 Mar 2000 17:09:01 -0800 (PST) From: ned.freed@innosoft.com Received: from MAUVE.INNOSOFT.COM by MAUVE.INNOSOFT.COM (PMDF V6.0-20 #35243) id <01JMVI0G109S000N0L@MAUVE.INNOSOFT.COM> for ietf-fax@imc.org; Sat, 11 Mar 2000 17:09:37 -0800 (PST) Date: Sat, 11 Mar 2000 16:43:41 -0800 (PST) Subject: RE: [VPIM] Analogy to Content-Duration for Faxes In-reply-to: "Your message dated Fri, 10 Mar 2000 11:00:45 -0600" <456E6DB7180ED3118A670000F8BDCA29021BADF9@zcard00p.ca.nortel.com> To: Glenn Parsons Cc: "'IETF VPIM List'" , "'ietf-fax@imc.org'" Message-id: <01JMWX8S830O000N0L@MAUVE.INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Now I remember :-) > It was one of the opitions described in for > message length indicator. I have exerted the section below. The original > intent of this was for clients to get this information via IMAP and present > it on the client. > Despite the ugliness of subject overloading, I am afraid that is what a lot > of products implement. I guess the question is do we want to endorse this, Well, an additional question is whether you'll be _able_ to endorse it in a standard. Let me say right now I'm strongly opposed to such mechanisms. For one thing, endorsing one may open the door to endorsing lots of others. And unlike other recent discussions like the "-xml" tag business, this is NOT an academic concern: There are so many subject line label thingies floating around already it isn't funny. Another issue is the potential for conflicting use. I would not care to bet that there isn't a conflicting use of parenthesized colon-separated numeric values other there -- indeed, I'm pretty sure I've encountered a couple over the past few years. Stuff that looks like it has a fair potential to fail to interoperate doesn't make it into IETF standards. And finally, past experience with embedding information as tags in unrelated header fields, even in contexts far less overloaded than the subject field, has been dismal at best. Two examples come immediately to mind: Storage of original and recipient information in comments in Received: fields and storage of certain delivery/return options in comments in To:/Cc:/Bcc:. Both of these uses have been the source of numerious operational problems. > or create a better mechanism (like the Conneg suggestion or one of the > others below). If we choose the latter, the client vendors have to agree to > implement it, or the industry will likely tend to what they do now. Conneg gives us a framework for this stuff. I think we should use it. Ned From owner-ietf-fax@mail.imc.org Mon Mar 13 16:52:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20230 for ; Mon, 13 Mar 2000 16:52:33 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA24001 for ietf-fax-bks; Mon, 13 Mar 2000 13:08:02 -0800 (PST) Received: from cserver.vadim.com.pl (cserver.vadim.com.pl [157.25.149.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA23955 for ; Mon, 13 Mar 2000 13:07:47 -0800 (PST) From: jan1@walesaremagic.co.uk Received: from localhost (unverified [63.249.254.3]) by cserver.vadim.com.pl (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 13 Mar 2000 22:08:48 +0100 Message-ID: X-Mailer: Internet Mail Service [15.0.3165.41] (Solaris; I) Date: Mon, 13 Mar 2000 15:21:21 X-Accept-Language: en To: Content-Transfer-Encoding: 7bit Subject: Email Advertising Works for You--We Guarantee Response!!! X-References: 0F8C8CA24, 0E5578ABD X-Other-References: 0EC3831BA X-In-Response-To: 0049DE8AC MessageID: Sensitivity: Company-Confidential Content-Type: text/html Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit E-MAIL-IT SPECIAL(Ends March 14/00) ADVERTISING THAT WORKS FOR YOU Call Ins Receive 25,000 Additional Emails at No Cost! For More information call 919-839-2942 or include your name and number in an email CLICK HERE For removal see link below. We Will Assist You in Developing Your Entire Campaign WE CAN CREATE YOUR AD FOR YOU Whether You Are Looking For Sales, Leads or Exposure OBC OFFERS Targeted or General Mailings With Fresh Addresses Always We GUARANTEE response ! We accept credit cards !SPECIAL Ends March 14, 2000 250,000 $250500,000 $450 1 MILLION $7752 MILLION $1395 Targeted Rates Upon Request For More Information Call: 919-839-2942 or include your name and number in an email and CLICK HERE subject=info for removal utilize link below. Call Ins Receive 25,000 Additional Emails at No Cost! +++++++++++++++++++++++++++++++++++++++++++ For Removal Mailto:leadtrash@mailcity.com?subject=remove From owner-ietf-fax@mail.imc.org Mon Mar 13 17:05:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24553 for ; Mon, 13 Mar 2000 17:05:52 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA24803 for ietf-fax-bks; Mon, 13 Mar 2000 13:33:45 -0800 (PST) Received: from aquaworld.co.jp ([210.248.29.146]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA24798 for ; Mon, 13 Mar 2000 13:33:43 -0800 (PST) From: janis2@mauimail.com Received: from localhost (unverified [63.249.254.3]) by aquaworld.co.jp (EMWAC SMTPRS 0.83) with SMTP id ; Tue, 14 Mar 2000 06:16:42 +0900 Message-ID: Date: Mon, 13 Mar 2000 15:32:09 References: 03468949F X-Other-References: 0F419BE3D X-Mailer: Mozilla 2.47 [en] (Win95; I) MessageID: Content-Transfer-Encoding: 7bit X-References: 097AD671F, 0A09807A4 MIME-Version: 1.0 To: Content-Type: text/html Subject: Email Advertising Special -- Ends Tuesday! X-In-Response-To: 0F491333A X-Accept-Language: en Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit E-MAIL-IT SPECIAL(Ends March 14/00) ADVERTISING THAT WORKS FOR YOU Call Ins Receive 25,000 Additional Emails at No Cost! For More information call 919-839-2942 or include your name and number in an email CLICK HERE For removal see link below. We Will Assist You in Developing Your Entire Campaign WE CAN CREATE YOUR AD FOR YOU Whether You Are Looking For Sales, Leads or Exposure OBC OFFERS Targeted or General Mailings With Fresh Addresses Always We GUARANTEE response ! We accept credit cards !SPECIAL Ends March 14, 2000 250,000 $250500,000 $450 1 MILLION $7752 MILLION $1395 Targeted Rates Upon Request For More Information Call: 919-839-2942 or include your name and number in an email and CLICK HERE subject=info for removal utilize link below. Call Ins Receive 25,000 Additional Emails at No Cost! +++++++++++++++++++++++++++++++++++++++++++ For Removal Mailto:leadtrash@mailcity.com?subject=remove From owner-ietf-fax@mail.imc.org Mon Mar 13 17:31:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03695 for ; Mon, 13 Mar 2000 17:31:47 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA25201 for ietf-fax-bks; Mon, 13 Mar 2000 13:59:23 -0800 (PST) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA25196; Mon, 13 Mar 2000 13:59:18 -0800 (PST) Message-Id: <4.3.2.20000313135720.00b6ae50@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 13 Mar 2000 14:00:36 -0800 To: James Rafferty From: Paul Hoffman / IMC Subject: RE: draft-ietf-fax-tiff-regbis-00.txt (resend with attachment) Cc: "'Glenn Parsons'" , "'Steve Zilles'" , "'IETF Fax List'" In-Reply-To: <11740AB18BD4D111BE8F00A0C9B8044F0227EE95@nhmail1.admin.bro oktrout.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:28 PM 3/7/00 -0500, James Rafferty wrote: >The contact information has changed. Hence, the ID needs to be submitted to >reflect this. There are no other changes. It would be good if you could put a note in the draft about that. There is no indication in the draft that this is an update to 2302. Also, why on earth did you make the boilerplate notice at the top say "except that the right to produce derivative works is not granted"? Was that a mistake? That kind of wording is completely inappropriate for a revision to a standards-track document whose distribution is unlimited. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-fax@mail.imc.org Thu Mar 16 16:53:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06077 for ; Thu, 16 Mar 2000 16:53:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA19434 for ietf-fax-bks; Thu, 16 Mar 2000 13:18:20 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA19429 for ; Thu, 16 Mar 2000 13:18:18 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23464; Thu, 16 Mar 2000 16:19:34 -0500 (EST) Message-Id: <200003162119.QAA23464@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-implementers-guide-01.txt Date: Thu, 16 Mar 2000 16:19:34 -0500 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 : Implementers Guide for Facsimile Using Internet Mail Author(s) : V. Cancio, M. Moldovan, H. Tamura Filename : draft-ietf-fax-implementers-guide-01.txt Pages : 16 Date : 15-Mar-00 This document is intended for the implementers of software which uses email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-implementers-guide-01.txt 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-implementers-guide-01.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-implementers-guide-01.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: <20000315132835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-implementers-guide-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-implementers-guide-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132835.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Thu Mar 16 22:16:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10885 for ; Thu, 16 Mar 2000 22:16:14 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA01413 for ietf-fax-bks; Thu, 16 Mar 2000 18:45:00 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA01405 for ; Thu, 16 Mar 2000 18:44:58 -0800 (PST) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id LAA03725; Fri, 17 Mar 2000 11:46:17 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id LAA25406; Fri, 17 Mar 2000 11:46:16 +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 LAA01210; Fri, 17 Mar 2000 11:41:49 +0900 (JST) To: agenda@ietf.org, ietf-fax@imc.org Cc: Claudio.Allocchio@elettra.trieste.it Subject: Final Agenda of Internet Fax WG at Adelaide meeting X-Mailer: Mew version 1.94.1 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Mar_17_11:45:49_2000_955)--" Content-Transfer-Encoding: 7bit Message-Id: <20000317115012J.tamura@toda.ricoh.co.jp> Date: Fri, 17 Mar 2000 11:50:12 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 62 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----Next_Part(Fri_Mar_17_11:45:49_2000_955)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attached is the agenda of Internet Fax WG Please prepare for the meeting. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) ----Next_Part(Fri_Mar_17_11:45:49_2000_955)-- Content-Type: Text/Plain; charset=us-ascii Content-Disposition: attachment; filename="Agenda.txt" Content-Transfer-Encoding: 7bit Internet Fax Extensions (fax) Thursday, March 30 at 1530-1730 ======================================================== Chairs: Claudio Allocchio Hiroshi Tamura Agenda: 5 min Opening - Introduction of new co-chairs - bashing Agenda 15 min Introduction of new charter - Getting consensus of the charter 15 min Status of drafts after WG Last Call - Drafts waiting for IETF approval draft-ietf-fax-feature-schema-v2-01.txt draft-ietf-fax-feature-T30-mapping-03.txt - Draft standards waiting for IETF approval draft-ietf-fax-tiff-fx-04.txt draft-ietf-fax-service-v2-01.txt draft-ietf-fax-faxaddr-v2-00.txt draft-ietf-fax-minaddr-v2-00.txt 55 min Review of drafts in action 10 min draft-ietf-fax-ffpim-0x.txt 15 min draft-ietf-fax-timely-delivery-0x.txt 15 min draft-ietf-fax-content-negotiation-0x.txt 15 min draft-ietf-fax-implementers-guide-01.txt 15 min On-going works 15 min TIFF-FX extension 10 min Introduction of cooperation with ITU - Report of SG8 February Meeting - Plan for ITU-T 5 min Other businesses and Closing ----Next_Part(Fri_Mar_17_11:45:49_2000_955)---- From owner-ietf-fax@mail.imc.org Sat Mar 18 14:11:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21455 for ; Sat, 18 Mar 2000 14:11:24 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA18483 for ietf-fax-bks; Sat, 18 Mar 2000 10:24:48 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18478 for ; Sat, 18 Mar 2000 10:24:46 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03619; Sat, 18 Mar 2000 13:26:16 -0500 (EST) Message-Id: <200003181826.NAA03619@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-content-negotiation-01.txt Date: Sat, 18 Mar 2000 13:26:15 -0500 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 : Content Negotiation for Facsimile Using Internet Mail Author(s) : G. Klyne, R. IWAZAKI, D. Crocker Filename : draft-ietf-fax-content-negotiation-01.txt Pages : 31 Date : 17-Mar-00 This memo describes a mechanism for e-mail content negotiation that allows Internet fax to transfer enhanced image data in a fashion comparable with traditional facsimile. It allows the sender of a message to indicate availability of alternative formats, and the receiver to indicate that an alternative format should be provided to replace the message data originally transmitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-content-negotiation-01.txt 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-content-negotiation-01.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-content-negotiation-01.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: <20000317103216.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-content-negotiation-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-content-negotiation-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000317103216.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Sun Mar 19 11:32:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26108 for ; Sun, 19 Mar 2000 11:32:10 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA26768 for ietf-fax-bks; Sun, 19 Mar 2000 08:08:03 -0800 (PST) Received: from elettra.trieste.it (SYNW10.elettra.trieste.it [140.105.2.12]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA26764 for ; Sun, 19 Mar 2000 08:08:01 -0800 (PST) Date: Sun, 19 Mar 2000 17:09:29 +0100 To: ietf-fax@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: VGA projector available Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallo, just for information to those who need to make a presentation during our next meeting: From: Steve Coya To: Claudio Allocchio Cc: Hiroshi Tamura Subject: Re: VGA/SVGA projector ? Hi Claudio Yes there WILL be a VGA projector. >>Do you know if there will be a VGA projector available in the FAX WG >>meeting room? Some of the draft authors would like to connect their PCs to >>make their presentations. From owner-ietf-fax@mail.imc.org Wed Mar 22 00:17:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05902 for ; Wed, 22 Mar 2000 00:17:21 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA22572 for ietf-fax-bks; Tue, 21 Mar 2000 20:35:45 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22567 for ; Tue, 21 Mar 2000 20:35:44 -0800 (PST) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id NAA08968 for ; Wed, 22 Mar 2000 13:37:25 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id NAA28648 for ; Wed, 22 Mar 2000 13:37:24 +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 NAA01534 for ; Wed, 22 Mar 2000 13:32:49 +0900 (JST) To: ietf-fax@imc.org Subject: Fw: Juridical value added fac-simile X-Mailer: Mew version 1.94.1 on Emacs 20.4 / Mule 4.1 (AOI) References: <20000321112921.16410.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000322134130N.tamura@toda.ricoh.co.jp> Date: Wed, 22 Mar 2000 13:41:30 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 30 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The following mail seems to be for ietf-fax@imc.org. From: "Gilbert Samicannou" Subject: Juridical value added fac-simile Date: Tue, 21 Mar 2000 03:29:21 PST > Dear Sir, > > I am currently working on a projet related to recognisation world wide of > fac-simile documents as juridical value added ones for juridical purposes. > "Juridical value" means fac-simile of juridical value. To be more precise : > Does a fac-simile document have a juridical value in front of a court? Does > it have the value of a proof? > I would like to ask if you know anyone currently working on this subject. > Please let me know his or her e-mail address if possible. Otherwise I will > be very much pleased to undertake this matter within IETF Fax WG if my > admission in the working group is allowed. > > Thanking You, > > M. SAMICANNOU Gilbert > 27, av. des Fleurs > 06000 Nice > France > Tel.: 04.93.86.75.95 > Fax : 12097294287 > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > From owner-ietf-fax@mail.imc.org Wed Mar 22 04:52:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28744 for ; Wed, 22 Mar 2000 04:52:04 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA06581 for ietf-fax-bks; Wed, 22 Mar 2000 01:22:31 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06577 for ; Wed, 22 Mar 2000 01:22:29 -0800 (PST) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id SAA08619 for ; Wed, 22 Mar 2000 18:24:20 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id SAA27898 for ; Wed, 22 Mar 2000 18:24:18 +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 SAA01601 for ; Wed, 22 Mar 2000 18:19:39 +0900 (JST) To: ietf-fax@imc.org Subject: RE: VGA projector available X-Mailer: Mew version 1.94.1 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: <20000322182821T.tamura@toda.ricoh.co.jp> Date: Wed, 22 Mar 2000 18:28:21 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 61 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Colleagues, The following mail is from Rafferty-san. To Presentors: It seems to be better to prepare traditional transparencies. Regards, From: James Rafferty Subject: RE: VGA projector available Date: Mon, 20 Mar 2000 10:52:01 -0500 > Claudio, Tamura-san, > > For your own presentations, I recommend that you still do transparencies. > Last time I tried to use the VGA projector and we got in trouble when we > started swapping PCs as different authors used the projector and then we > tried to switch back to my PC with poor results. > > So, if your own presentations are with transparencies, this at least makes > your ability to run the meeting much easier. Then, the authors can use the > VGA projector as needed. > > James > > > -----Original Message----- > > From: Claudio Allocchio [mailto:Claudio.Allocchio@elettra.trieste.it] > > Sent: Sunday, March 19, 2000 11:09 AM > > To: ietf-fax@imc.org > > Subject: VGA projector available > > > > > > > > Hallo, > > > > just for information to those who need to make a presentation > > during our > > next meeting: > > > > From: Steve Coya > > To: Claudio Allocchio > > Cc: Hiroshi Tamura > > Subject: Re: VGA/SVGA projector ? > > > > > > Hi Claudio > > > > Yes there WILL be a VGA projector. > > > > >>Do you know if there will be a VGA projector available in > > the FAX WG > > >>meeting room? Some of the draft authors would like to > > connect their PCs to > > >>make their presentations. > > -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@mail.imc.org Wed Mar 22 09:47:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13221 for ; Wed, 22 Mar 2000 09:47:39 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA18504 for ietf-fax-bks; Wed, 22 Mar 2000 06:12:44 -0800 (PST) Received: from Brooktrout.Com (truite.brooktrout.com [204.176.74.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18499 for ; Wed, 22 Mar 2000 06:12:42 -0800 (PST) Received: from nhmail1.admin.brooktrout.com (nhmail1.admin.brooktrout.com [204.176.75.8]) by Brooktrout.Com (8.9.3/8.9.3/BTI-2.1) with ESMTP id IAA03520; Wed, 22 Mar 2000 08:56:09 -0500 Received: by nhmail1.admin.brooktrout.com with Internet Mail Service (5.5.2448.0) id ; Wed, 22 Mar 2000 09:04:40 -0500 Message-ID: <11740AB18BD4D111BE8F00A0C9B8044F029DD252@nhmail1.admin.brooktrout.com> From: James Rafferty To: "'Hiroshi Tamura'" , ietf-fax@imc.org Subject: RE: VGA projector available Date: Wed, 22 Mar 2000 09:04:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To all - Actually, I was just recommending that the slides from the chairs be on transparencies, to reduce meeting interruptions when switching from one presentation to another. For authors who want to refer to specific sections of documents or just have 1-2 slides, the VGA projector is still probably the easiest way. Enjoy Australia. I'll have to make it "down under" another time. Best Regards, James > -----Original Message----- > From: Hiroshi Tamura [mailto:tamura@toda.ricoh.co.jp] > Sent: Wednesday, March 22, 2000 4:28 AM > To: ietf-fax@imc.org > Subject: RE: VGA projector available > > > Dear Colleagues, > > The following mail is from Rafferty-san. > > To Presentors: > It seems to be better to prepare traditional transparencies. > > Regards, > > From: James Rafferty > Subject: RE: VGA projector available > Date: Mon, 20 Mar 2000 10:52:01 -0500 > > > Claudio, Tamura-san, > > > > For your own presentations, I recommend that you still do > transparencies. > > Last time I tried to use the VGA projector and we got in > trouble when we > > started swapping PCs as different authors used the > projector and then we > > tried to switch back to my PC with poor results. > > > > So, if your own presentations are with transparencies, this > at least makes > > your ability to run the meeting much easier. Then, the > authors can use the > > VGA projector as needed. > > > > James > > > > > -----Original Message----- > > > From: Claudio Allocchio > [mailto:Claudio.Allocchio@elettra.trieste.it] > > > Sent: > Sunday, March 19, 2000 11:09 AM > > > To: ietf-fax@imc.org > > > Subject: VGA projector available > > > > > > > > > > > > Hallo, > > > > > > just for information to those who need to make a presentation > > > during our > > > next meeting: > > > > > > From: Steve Coya > > > To: Claudio Allocchio > > > Cc: Hiroshi Tamura > > > Subject: Re: VGA/SVGA projector ? > > > > > > > > > Hi Claudio > > > > > > Yes there WILL be a VGA projector. > > > > > > >>Do you know if there will be a VGA projector available in > > > the FAX WG > > > >>meeting room? Some of the draft authors would like to > > > connect their PCs to > > > >>make their presentations. > > > > > -- > Hiroshi Tamura, Ricoh Company, LTD. > Mail: tamura@toda.ricoh.co.jp > Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) > From owner-ietf-fax@mail.imc.org Wed Mar 22 16:50:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17018 for ; Wed, 22 Mar 2000 16:50:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA26772 for ietf-fax-bks; Wed, 22 Mar 2000 13:24:31 -0800 (PST) Received: from Brooktrout.Com (truite.brooktrout.com [204.176.74.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26767 for ; Wed, 22 Mar 2000 13:24:29 -0800 (PST) Received: from nhmail1.admin.brooktrout.com (nhmail1.admin.brooktrout.com [204.176.75.8]) by Brooktrout.Com (8.9.3/8.9.3/BTI-2.1) with ESMTP id QAA05203; Wed, 22 Mar 2000 16:14:00 -0500 Received: from jraff.brooktrout.com (dhcp24.sales.brooktrout.com [204.176.75.171]) by nhmail1.admin.brooktrout.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id HHFX6JJT; Wed, 22 Mar 2000 16:22:33 -0500 Message-Id: X-Sender: jrafferty@humancomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 22 Mar 2000 16:14:21 -0500 To: TSG8IFAX , Ietf-Fax From: James Rafferty Subject: Article on IETF/ITU Process for Internet Fax Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To all - The March issue of Upstart ( a magazne about Telephony) has a pretty good article about the ITU and the IETF and their different standards processes. The author Bridget Testa interviewed myself and several of my IETF/ITU stds colleagues for it. Our work on Internet fax is featured. This article might help the next time you hear someone complain about long standards processes; as we know first hand, often the issues are as much cultural as technical. The URL is: http://www.internettelephony.com/asp/Supp_Display.asp?SuppStoryID=496&SuppTy peID=5 James From owner-ietf-fax@mail.imc.org Thu Mar 23 07:10:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03163 for ; Thu, 23 Mar 2000 07:10:26 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA06869 for ietf-fax-bks; Thu, 23 Mar 2000 03:33:50 -0800 (PST) Received: from hotmail.com (law2-f12.hotmail.com [216.32.181.12]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA06865 for ; Thu, 23 Mar 2000 03:33:49 -0800 (PST) Received: (qmail 85947 invoked by uid 0); 23 Mar 2000 11:35:16 -0000 Message-ID: <20000323113516.85946.qmail@hotmail.com> Received: from 193.251.80.13 by www.hotmail.com with HTTP; Thu, 23 Mar 2000 03:35:16 PST X-Originating-IP: [193.251.80.13] From: "Gilbert Samicannou" To: ietf-fax@imc.org Subject: Juridical value added fac-simile Date: Thu, 23 Mar 2000 03:35:16 PST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Colleagues, I am currently working on a projet related to recognisation world wide of fac-simile documents as juridical value added ones for juridical purposes. "Juridical value" means fac-simile of juridical value. To be more precise : Does a fac-simile document have a juridical value in front of a court? Does it have the value of a proof? I would like to ask if you know anyone currently working on this subject. Please let me know his or her e-mail address if possible. Otherwise I will be very much pleased to undertake this matter within IETF Fax WG if my admission in the working group is allowed. Thanking You, M. SAMICANNOU Gilbert 27, av. des Fleurs 06000 Nice France Tel.: 04.93.86.75.95 Fax : 12097294287 ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ietf-fax@mail.imc.org Thu Mar 23 12:50:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06537 for ; Thu, 23 Mar 2000 12:50:22 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA13712 for ietf-fax-bks; Thu, 23 Mar 2000 09:15:50 -0800 (PST) Received: from laptop.imc.org (user@ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13708 for ; Thu, 23 Mar 2000 09:15:49 -0800 (PST) Message-Id: <4.3.2.20000323091730.00c642c0@not-real.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 23 Mar 2000 09:18:38 -0800 To: ietf-fax@imc.org From: Paul Hoffman / IMC Subject: Yet another patent Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Of probable interest to this WG. I have no idea if this is valid or interesting. Innovative Technology Enables the Worldwide Installed Base of Fax Machines to Send Documents to Email ATLANTA, March 22 /PRNewswire/ -- E-mate.com LLC announced today that it has been issued United States Patent 6,023,345 and United States Patent 6,025,931 for technology, which the company believes, will radically change the way businesses deliver hard-copy documents over the Internet. By using E- mate.com's patented solution, businesses can use their existing fax machines as "input" devices to send hard-copy documents to any email recipient in the world. A recipient retrieves and views the document as an image file in the ordinary course of reading their email. This capability is significant in that the technology enables the 100 plus million installed-base of fax machines to become instantly "email compatible" for sending hard-copy documents directly to recipients who have an email address. According to Mark Bloomfield, E-mate's founder and CEO, "The patents are significant because the company owns the basic procedure, design, and techniques for sending documents from a fax machine to email. The only other way to accomplish this task is to replace existing standard fax machines with expensive IP-enabled machines or IP adjunct devices. Our technology represents a simpler, cheaper and more universal solution." The company has additional patents pending in the U.S. and has foreign applications in 17 other countries. The E-mate service includes a small keypad device that when plugged into the accessory phone jack of the user's fax machine, becomes the interface and connection to the Internet. The keypad contains the technology required for the fax machine to communicate with Internet servers for delivering a document to email. Using this keypad, a user enters an email address or recalls one stored in memory and initiates a call. The document to be delivered is placed in the fax machine tray and is scanned, then delivered via the Internet to the recipient's email. There are no busy signals and no fax cover sheets. E-mate works with any fax machine and anywhere in the world. The technology incorporated in the keypad can be software embedded into future fax machines so that new machines are "E-mate-enabled" out of the box. Furthermore, the software could be embedded into a myriad of other Internet devices such as Internet phones, Internet appliances, and portable organizers/communicators. In this scenario, the E-mate application would perform the same functions as the E-mate "keypad." In portable devices, the E-mate service would be especially useful for users who wish to have E-mate capability while traveling. E-mate.com is a privately held, Atlanta, Ga.-based R&D firm formed specifically to develop and patent the E-mate technology. Now that the patents have been issued, E-mate.com is seeking strategic partners who can rapidly commercialize the technology and bring the services to market. In this regard, the company has retained First Union Securities and Atlanta-based TDRC, a nationally recognized IP technology-consulting firm, to identify companies who may have an interest in purchasing the E-mate.com technology. "We believe the E-mate story is a good one and represents a significant opportunity," states Don Erb, Director of Technology Investment Banking for First Union Securities. "E-mate.com has many of the components we look for in technology winners. The technology provides a first-to-market position, the technology possesses 'viral marketing' attributes in that every user becomes a seller, and finally, the new patents provide a strong barrier to entry from competitors. We are pleased to assist the company in finding the right strategic partners who can help bring this technology to the market." Adds David A. Kennedy, Executive V.P. of TDRC, "The E-mate technology is here today and it works. Our firm has been using the E-mate service as a beta customer for several months. Most of the people we do business with have email and so its only natural that this is the medium we like to use to send them our hard-copy and fax documents. Not only has it reduced our long distance bill, but it is simply a better solution than faxing, mail, scanning or overnight delivery." Web site (demonstration only): http://www.e-mate.com SOURCE E-mate.com CONTACT: Mark Bloomfield of E-mate.com LLC, 770-850-9126, or mcb@bellsouth.net , or Donald G. Erb of First Union Securities, 404-827-7448, or donald.erb@funb.com , or David Kennedy of TDRC, 404-253-7900, or dkennedy@tdrc.com Web site: http://www.e-mate.com --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-fax@mail.imc.org Sun Mar 26 05:03:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14517 for ; Sun, 26 Mar 2000 05:03:00 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA19306 for ietf-fax-bks; Sun, 26 Mar 2000 01:28:20 -0800 (PST) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA19298 for ; Sun, 26 Mar 2000 01:28:14 -0800 (PST) Date: Sun, 26 Mar 2000 11:29:53 +0100 To: internet-drafts@ietf.org cc: ietf-fax@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Delete I-Ds Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallo, ---------- Forwarded message ---------- Date: Wed, 22 Mar 2000 16:13:53 -0800 From: Paul Hoffman / IMC To: Claudio Allocchio , Hiroshi Tamura FYI, the Secretariat deleted the following drafts because they were >6 months old: draft-ietf-fax-capability-scenarios draft-ietf-fax-confirmation-scenarios draft-ietf-fax-faxaddr-v2 draft-ietf-fax-mdn-fullmode draft-ietf-fax-minaddr-v2 draft-ietf-fax-service-v2 --Paul Hoffman, Director --Internet Mail Consortium I'm sorry to say that we (the IETF organisation) cannot afford to be very efficient in deliting drafts older than 6 moths, when the IESG is unable to process the requests before an average time of 10 months !! I please ask the internet drafts maintenance people to re-post agin the above drafts in the I-D directories. Thye' all under Last call, or even "passed" the last call. Thank you indeed !! Claudio Allocchio ietf-fax co-chair From owner-ietf-fax@mail.imc.org Tue Mar 28 04:00:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18511 for ; Tue, 28 Mar 2000 04:00:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA14908 for ietf-fax-bks; Tue, 28 Mar 2000 00:28:19 -0800 (PST) Received: from pp-mx0.tokyo.spin.ad.jp (PP-mx0.Tokyo.Spin.AD.JP [165.76.52.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA14903 for ; Tue, 28 Mar 2000 00:28:17 -0800 (PST) Received: from localhost (dhcp-34-20.ietf.connect.com.au [169.208.34.20]) by pp-mx0.tokyo.spin.ad.jp (8.8.8+Spin/3.6W-JENS-stand2(10/10/99)) id RAA28128; Tue, 28 Mar 2000 17:30:20 +0900 (JST) To: ietf-fax@imc.org Subject: [IETF-FAX] Addition to Agenda. From: tamura@toda.ricoh.co.jp Reply-To: tamura@toda.ricoh.co.jp X-Mailer: Mew version 1.94.1 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: <20000328173054V.adm@ifax.attnet.ne.jp> Date: Tue, 28 Mar 2000 17:30:54 +0900 (JST) X-Dispatcher: imput version 990905(IM130) Lines: 17 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Colleagues, A person asked me that he would like to make a presentation at our meeting about Fax-Gateway issue. He requests only 5 minutes, so Allocchio-san and I accepted it. Before closing our meeting, he will do it. I do not know if his idea is good/suitable for our wg/ useful or not. Because it is not based on SMTP. Anyway, he promised to me that he will circulte his detailed idea in our ML, sooner or later. Regards, -- Hiroshi Tamura(tamura@toda.ricoh.co.jp) From owner-ietf-fax@mail.imc.org Tue Mar 28 10:08:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21854 for ; Tue, 28 Mar 2000 10:08:13 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA02782 for ietf-fax-bks; Tue, 28 Mar 2000 06:27:40 -0800 (PST) Received: from jog.kuis.kyoto-u.ac.jp (jog.kuis.kyoto-u.ac.jp [130.54.22.113]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02777 for ; Tue, 28 Mar 2000 06:27:35 -0800 (PST) Received: (from kitagawa@localhost) by jog.kuis.kyoto-u.ac.jp (8.8.8/8.8.8) id XAA03805; Tue, 28 Mar 2000 23:29:56 +0900 (JST) (envelope-from kitagawa) To: ietf-fax@imc.org Subject: Re: [IETF-FAX] Addition to Agenda. References: <20000328173054V.adm@ifax.attnet.ne.jp> From: KITAGAWA Takurou In-Reply-To: <20000328173054V.adm@ifax.attnet.ne.jp> (tamura@toda.ricoh.co.jp's message of "Tue, 28 Mar 2000 17:30:54 +0900 (JST)") MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII Date: 28 Mar 2000 23:29:55 +0900 Message-ID: <3gzorj182k.fsf@jog.kuis.kyoto-u.ac.jp> Lines: 136 User-Agent: Semi-gnus/6.10.12 SEMI/1.13.4 (Terai) FLIM/1.12.7 (=?ISO-8859-4?Q?Y=FEzaki?=) Emacs/20.4 (i386-unknown-freebsd2.2.6) MULE/4.0 (HANANOEN) Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: tamura@toda.ricoh.co.jp writes: > Dear Colleagues, > > A person asked me that he would like to make a presentation > at our meeting about Fax-Gateway issue. > > He requests only 5 minutes, so Allocchio-san and I accepted it. > Before closing our meeting, he will do it. > > I do not know if his idea is good/suitable for our wg/ > useful or not. Because it is not based on SMTP. > > Anyway, he promised to me that he will circulte his detailed idea > in our ML, sooner or later. > > Regards, > -- > Hiroshi Tamura(tamura@toda.ricoh.co.jp) --------------------------------------------------------------------------- Directory Server for Internet Fax with HTTP and CGI Abstract A directory server, which receives a traditional fax number of G3fax, and returns the information of "offramp" gateway, used by a terminal on the Internet to send facsimile to G3fax, is defined. This server uses HTTP and CGI mechanism to communicate with a terminal. 1. Introduction An Internet FAX uses an "offramp" gateway to send facsimile to a terminal located at PSTN. But, if users must input a address of a gateway for each sending, it bothers them very much. Thus, when a terminal itself can get the information of gateway, a user have to input only a fax number. This is a same user interface as one of G3fax, and Internet Fax will become easier to use. In this draft, a directory server, which finds a best offramp gateway, according to a fax number inputed by a user, and notifies it to a fax terminal on the Internet. This server uses HTTP and CGI mechanism to communicate with a client. 2. Query from client to server A client, or a fax terminal on the Internet, accesses to following URI with HTTP, using a GET method. http:///[path]? is the host name (or IP address) of the directory server. A server MAY require [path], to specify a directory in it. is the fax number of G3fax given by a user, and it is composed of digit 0-9, *, and/or #. and [path] in this URI, which are required information to specify a directory, are set up in a client in advance. 3. Answer from server to client A server receives a fax number given by a client with the CGI mechanism. Then a sever looks for a gateway, which works well for the requested fax number. 3.1 The case that server found the gateway A server returns HTTP status code 200 (OK) to a client, and a body part of the reply contins the information of a gateway. As the description format of the information, we can be use the format defined in [draft-ietf-fax-fulladdr-06.txt]. Example: ( C> indicates the data from client to server, and S> indicates the data from client to server ) C>GET /?12345678 HTTP/1.0 C> S>200 OK S>Content-Type: application/x-fax-address S> S>FAX=+12345678@faxgw 3.2 The case that the server could not find the gateway A server returns HTTP status code 404 (Not Found) to a client. Example: C>GET /?87654321 HTTP/1.0 C> S>404 Not Found S> 3.3 Timeout A client waits for an answer from a server during the specified time after it sent an query. When a client receives no answer from a server during the time, it judges that a server error occurred. 3.5 Other status codes A server MAY return other status codes to a client if necessary. When a client receives an HTTP Status Code not described above, it SHOULD deal it as an usual HTTP user agents does. 4. Security A telephone directory server MAY authenticate a client in accordance with the HTTP framework, if necessary. --------------------------------------------------------------------------- -- KITAGAWA Takurou Graduate School of Informatics, Kyoto University kitagawa@kuis.kyoto-u.ac.jp From owner-ietf-fax@mail.imc.org Tue Mar 28 11:53:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23504 for ; Tue, 28 Mar 2000 11:53:44 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA04548 for ietf-fax-bks; Tue, 28 Mar 2000 08:11:50 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04544 for ; Tue, 28 Mar 2000 08:11:48 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA18381; Tue, 28 Mar 2000 08:13:08 -0800 (PST) Date: Tue, 28 Mar 2000 08:13:07 -0800 (PST) From: Dan Wing To: KITAGAWA Takurou cc: ietf-fax@imc.org Subject: Re: [IETF-FAX] Addition to Agenda. In-Reply-To: <3gzorj182k.fsf@jog.kuis.kyoto-u.ac.jp> Message-ID: <0003280810230.14651-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A few comments on this proposal: 1. E.164 -> DNS mapping works just as well as this proposal and scales to the largest enterprise or telephone company. 2. Is there supposed to be an Internet-wide authority on the "best" offramp for everyone to use? 3. Why HTTP instead of LDAP? Because HTTP is ubiquitous? -Dan Wing On 28 Mar 2000 23:29 +0900, KITAGAWA Takurou wrote: > > tamura@toda.ricoh.co.jp writes: > > > Dear Colleagues, > > > > A person asked me that he would like to make a presentation > > at our meeting about Fax-Gateway issue. > > > > He requests only 5 minutes, so Allocchio-san and I accepted it. > > Before closing our meeting, he will do it. > > > > I do not know if his idea is good/suitable for our wg/ > > useful or not. Because it is not based on SMTP. > > > > Anyway, he promised to me that he will circulte his detailed idea > > in our ML, sooner or later. > > > > Regards, > > -- > > Hiroshi Tamura(tamura@toda.ricoh.co.jp) > > --------------------------------------------------------------------------- > Directory Server for Internet Fax with HTTP and CGI > > Abstract > > A directory server, which receives a traditional > fax number of G3fax, and returns the information of "offramp" > gateway, used by a terminal on the Internet to send facsimile > to G3fax, is defined. > This server uses HTTP and CGI mechanism to communicate with a > terminal. > > 1. Introduction > > An Internet FAX uses an "offramp" gateway to send facsimile to a > terminal located at PSTN. > > But, if users must input a address of a gateway for each sending, > it bothers them very much. > > Thus, when a terminal itself can get the information of gateway, > a user have to input only a fax number. > This is a same user interface as one of G3fax, and Internet Fax will > become easier to use. > > In this draft, a directory server, which finds a best offramp > gateway, according to a fax number inputed by a user, and notifies it > to a fax terminal on the Internet. > > This server uses HTTP and CGI mechanism to communicate with a client. > > > 2. Query from client to server > > A client, or a fax terminal on the Internet, accesses to > following URI with HTTP, using a GET method. > > http:///[path]? > > is the host name (or IP address) of the directory server. > > A server MAY require [path], to specify a directory in it. > > is the fax number of G3fax given by a user, and it is > composed of digit 0-9, *, and/or #. > > and [path] in this URI, which are required information to > specify a directory, are set up in a client in advance. > > 3. Answer from server to client > > A server receives a fax number given by a client with the CGI > mechanism. > Then a sever looks for a gateway, which works well for the > requested fax number. > > 3.1 The case that server found the gateway > > A server returns HTTP status code 200 (OK) to a client, > and a body part of the reply contins the information of a gateway. > > As the description format of the information, we can be use the format > defined in [draft-ietf-fax-fulladdr-06.txt]. > > Example: > > ( C> indicates the data from client to server, and S> indicates the > data from client to server ) > > C>GET /?12345678 HTTP/1.0 > C> > S>200 OK > S>Content-Type: application/x-fax-address > S> > S>FAX=+12345678@faxgw > > > 3.2 The case that the server could not find the gateway > > A server returns HTTP status code 404 (Not Found) to a client. > > Example: > > C>GET /?87654321 HTTP/1.0 > C> > S>404 Not Found > S> > > > 3.3 Timeout > > A client waits for an answer from a server during the specified time > after it sent an query. > When a client receives no answer from a server during the time, > it judges that a server error occurred. > > > 3.5 Other status codes > > A server MAY return other status codes to a client if necessary. > When a client receives an HTTP Status Code not described above, > it SHOULD deal it as an usual HTTP user agents does. > > > 4. Security > > A telephone directory server MAY authenticate a client in accordance > with the HTTP framework, if necessary. > > --------------------------------------------------------------------------- > > -- > KITAGAWA Takurou > Graduate School of Informatics, Kyoto University > kitagawa@kuis.kyoto-u.ac.jp > From owner-ietf-fax@mail.imc.org Tue Mar 28 19:39:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00475 for ; Tue, 28 Mar 2000 19:39:19 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA12106 for ietf-fax-bks; Tue, 28 Mar 2000 16:08:04 -0800 (PST) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12102 for ; Tue, 28 Mar 2000 16:08:03 -0800 (PST) From: rshockey@ix.netcom.com Received: from smui1.atl.mindspring.net (smui1.atl.mindspring.net [207.69.200.121]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id TAA05103 for ; Tue, 28 Mar 2000 19:10:27 -0500 (EST) Received: by smui1.atl.mindspring.net id TAA0000011749; Tue, 28 Mar 2000 19:10:27 -0500 (EST) Date: Tue, 28 Mar 2000 19:10:27 -0500 To: ietf-fax@imc.org Subject: Addition to agenda.. Message-ID: X-Originating-IP: 169.208.127.6 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Tue, 28 Mar 2000 08:13:07 -0800 (PST) From: Dan Wing To: KITAGAWA Takurou cc: ietf-fax@imc.org Subject: Re: [IETF-FAX] Addition to Agenda. In-Reply-To: <3gzorj182k.fsf@jog.kuis.kyoto-u.ac.jp> Message-ID: <0003280810230.14651-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A few comments on this proposal: 1. E.164 -> DNS mapping works just as well as this proposal and scales to the largest enterprise or telephone company. 2. Is there supposed to be an Internet-wide authority on the "best" offramp for everyone to use? 3. Why HTTP instead of LDAP? Because HTTP is ubiquitous? -Dan Wing On 28 Mar 2000 23:29 +0900, KITAGAWA Takurou wrote: > > tamura@toda.ricoh.co.jp writes: > > > Dear Colleagues, > > > > A person asked me that he would like to make a presentation > > at our meeting about Fax-Gateway issue. > > > > He requests only 5 minutes, so Allocchio-san and I accepted it. > > Before closing our meeting, he will do it. > > > > I do not know if his idea is good/suitable for our wg/ > > useful or not. Because it is not based on SMTP. > > > > Anyway, he promised to me that he will circulte his detailed idea > > in our ML, sooner or later. > > > > Regards, > > -- > > Hiroshi Tamura(tamura@toda.ricoh.co.jp) > > --------------------------------------------------------------------------- > Directory Server for Internet Fax with HTTP and CGI > > Abstract > > A d From owner-ietf-fax@mail.imc.org Tue Mar 28 19:44:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00571 for ; Tue, 28 Mar 2000 19:44:01 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA12174 for ietf-fax-bks; Tue, 28 Mar 2000 16:11:41 -0800 (PST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12168 for ; Tue, 28 Mar 2000 16:11:38 -0800 (PST) From: rshockey@ix.netcom.com Received: from smui4.eng00.mindspring.net (smui4.eng00.mindspring.net [207.69.200.49]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id TAA05156 for ; Tue, 28 Mar 2000 19:14:02 -0500 (EST) Received: by smui4.eng00.mindspring.net id TAA0000012487; Tue, 28 Mar 2000 19:14:02 -0500 (EST) Date: Tue, 28 Mar 2000 19:14:02 -0500 To: ietf-fax@imc.org Subject: Addition to agenda.. Message-ID: X-Originating-IP: 169.208.127.6 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A few notes.. ************* Date: Tue, 28 Mar 2000 08:13:07 -0800 (PST) From: Dan Wing To: KITAGAWA Takurou cc: ietf-fax@imc.org Subject: Re: [IETF-FAX] Addition to Agenda. In-Reply-To: <3gzorj182k.fsf@jog.kuis.kyoto-u.ac.jp> Message-ID: <0003280810230.14651-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A few comments on this proposal: 1. E.164 -> DNS mapping works just as well as this proposal and scales to the largest enterprise or telephone company. EXACTLY .. THIS IS THE ENUM PROPOSAL IN THE IETF. 2. Is there supposed to be an Internet-wide authority on the "best" offramp for everyone to use? THIS IS THE TRIP ISSUE IN THE IPTEL WG.... 3. Why HTTP instead of LDAP? Because HTTP is ubiquitous? YOU DONT USE HTTP, UNLESS YOU WANT TO HAVE THE SAME PROBLEMS THE IPP WG HAS HAD OVER THE YEARS. THE IETF IS VERY VERY STRICT THESE DAYS ON THE USE OF HTTP IN APPLICATION PROTOCOLS. -Dan Wing On 28 Mar 2000 23:29 +0900, KITAGAWA Takurou wrote: > > tamura@toda.ricoh.co.jp writes: > > > Dear Colleagues, > > > > A person asked me that he would like to make a presentation > > at our meeting about Fax-Gateway issue. > > > > He requests only 5 minutes, so Allocchio-san and I accepted it. > > Before closing our meeting, he will do it. > > > > I do not know if his idea is good/suitable for our wg/ > > useful or not. Because it is not based on SMTP. > > > > Anyway, he promised to me that he will circulte his detailed idea > > in our ML, sooner or later. > > > > Regards, > > -- > > Hiroshi Tamura(tamura@toda.ricoh.co.jp) > > --------------------------------------------------------------------------- > Directory Server for Internet Fax with HTTP and CGI > > Abstract > > A d From owner-ietf-fax@mail.imc.org Tue Mar 28 20:50:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01105 for ; Tue, 28 Mar 2000 20:50:24 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA13119 for ietf-fax-bks; Tue, 28 Mar 2000 17:07:21 -0800 (PST) Received: from jog.kuis.kyoto-u.ac.jp (jog.kuis.kyoto-u.ac.jp [130.54.22.113]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA13113 for ; Tue, 28 Mar 2000 17:07:19 -0800 (PST) Received: (from kitagawa@localhost) by jog.kuis.kyoto-u.ac.jp (8.8.8/8.8.8) id KAA04676; Wed, 29 Mar 2000 10:09:28 +0900 (JST) (envelope-from kitagawa) To: Dan Wing Cc: ietf-fax@imc.org Subject: Re: [IETF-FAX] Addition to Agenda. References: <3gzorj182k.fsf@jog.kuis.kyoto-u.ac.jp> <0003280810230.14651-100000@omega.cisco.com> From: KITAGAWA Takurou In-Reply-To: <0003280810230.14651-100000@omega.cisco.com> (Dan Wing's message of "Tue, 28 Mar 2000 08:13:07 -0800 (PST)") MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII Date: 29 Mar 2000 10:09:26 +0900 Message-ID: <3gwvmm1t15.fsf@jog.kuis.kyoto-u.ac.jp> Lines: 205 User-Agent: Semi-gnus/6.10.12 SEMI/1.13.4 (Terai) FLIM/1.12.7 (=?ISO-8859-4?Q?Y=FEzaki?=) Emacs/20.4 (i386-unknown-freebsd2.2.6) MULE/4.0 (HANANOEN) Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Dan; Thank you for your comments. Dan Wing writes: > A few comments on this proposal: > > 1. E.164 -> DNS mapping works just as well as this proposal and scales > to the largest enterprise or telephone company. > > 2. Is there supposed to be an Internet-wide authority on the > "best" offramp for everyone to use? Of course, "best" offramp is different between users, it depends on a local policy of each user. And this is the reason why a terminal doesn't use E.164 -> DNS mapping directly, i.e. ENUM. It is not a solution for a local policy management. An implementation of a typical direcotry server is as follows (but note that this is an example): 1. A server receive a fax number 2. A server looks up its own local database, which is built according to its local policy. 3. If the information of gateway is found in local database of a server, a server returns it to a terminal. 4. If a server could not find the information in local database, it looks up a global database, ENUM for example, and returns a result. There may be many directory servers in the Internet. They are managed by many providors or carriers, and have their own policies. A user choose one (or more) directory server from them, according to a user's policy, and set a terminal up with chosen server(s). Then there is another reason that the ENUM framwork is hard to be used directly from a terminal. When a server receive a number like "+81-3-xxx-xxxx", a terminal expects the information of an offramp localed in Tokyo, like "FAX=+xxxxxxx@tokyogw.internetfax.com". If a server want to do such conversion in ENUM framework, it has to contain many, many entries for each number starting at "+81-3-", or requires specialized implementation for it. > 3. Why HTTP instead of LDAP? Because HTTP is ubiquitous? Because with HTTP, a server can be implemented easily. I have already implemented this directory server with Apache and Perl, in less than an hour. Regards, -- KITAGAWA Takurou Graduate School of Informatics, Kyoto University kitagawa@kuis.kyoto-u.ac.jp > > -Dan Wing > > > On 28 Mar 2000 23:29 +0900, KITAGAWA Takurou wrote: > > > > > tamura@toda.ricoh.co.jp writes: > > > > > Dear Colleagues, > > > > > > A person asked me that he would like to make a presentation > > > at our meeting about Fax-Gateway issue. > > > > > > He requests only 5 minutes, so Allocchio-san and I accepted it. > > > Before closing our meeting, he will do it. > > > > > > I do not know if his idea is good/suitable for our wg/ > > > useful or not. Because it is not based on SMTP. > > > > > > Anyway, he promised to me that he will circulte his detailed idea > > > in our ML, sooner or later. > > > > > > Regards, > > > -- > > > Hiroshi Tamura(tamura@toda.ricoh.co.jp) > > > > --------------------------------------------------------------------------- > > Directory Server for Internet Fax with HTTP and CGI > > > > Abstract > > > > A directory server, which receives a traditional > > fax number of G3fax, and returns the information of "offramp" > > gateway, used by a terminal on the Internet to send facsimile > > to G3fax, is defined. > > This server uses HTTP and CGI mechanism to communicate with a > > terminal. > > > > 1. Introduction > > > > An Internet FAX uses an "offramp" gateway to send facsimile to a > > terminal located at PSTN. > > > > But, if users must input a address of a gateway for each sending, > > it bothers them very much. > > > > Thus, when a terminal itself can get the information of gateway, > > a user have to input only a fax number. > > This is a same user interface as one of G3fax, and Internet Fax will > > become easier to use. > > > > In this draft, a directory server, which finds a best offramp > > gateway, according to a fax number inputed by a user, and notifies it > > to a fax terminal on the Internet. > > > > This server uses HTTP and CGI mechanism to communicate with a client. > > > > > > 2. Query from client to server > > > > A client, or a fax terminal on the Internet, accesses to > > following URI with HTTP, using a GET method. > > > > http:///[path]? > > > > is the host name (or IP address) of the directory server. > > > > A server MAY require [path], to specify a directory in it. > > > > is the fax number of G3fax given by a user, and it is > > composed of digit 0-9, *, and/or #. > > > > and [path] in this URI, which are required information to > > specify a directory, are set up in a client in advance. > > > > 3. Answer from server to client > > > > A server receives a fax number given by a client with the CGI > > mechanism. > > Then a sever looks for a gateway, which works well for the > > requested fax number. > > > > 3.1 The case that server found the gateway > > > > A server returns HTTP status code 200 (OK) to a client, > > and a body part of the reply contins the information of a gateway. > > > > As the description format of the information, we can be use the format > > defined in [draft-ietf-fax-fulladdr-06.txt]. > > > > Example: > > > > ( C> indicates the data from client to server, and S> indicates the > > data from client to server ) > > > > C>GET /?12345678 HTTP/1.0 > > C> > > S>200 OK > > S>Content-Type: application/x-fax-address > > S> > > S>FAX=+12345678@faxgw > > > > > > 3.2 The case that the server could not find the gateway > > > > A server returns HTTP status code 404 (Not Found) to a client. > > > > Example: > > > > C>GET /?87654321 HTTP/1.0 > > C> > > S>404 Not Found > > S> > > > > > > 3.3 Timeout > > > > A client waits for an answer from a server during the specified time > > after it sent an query. > > When a client receives no answer from a server during the time, > > it judges that a server error occurred. > > > > > > 3.5 Other status codes > > > > A server MAY return other status codes to a client if necessary. > > When a client receives an HTTP Status Code not described above, > > it SHOULD deal it as an usual HTTP user agents does. > > > > > > 4. Security > > > > A telephone directory server MAY authenticate a client in accordance > > with the HTTP framework, if necessary. > > > > --------------------------------------------------------------------------- > > > > -- > > KITAGAWA Takurou > > Graduate School of Informatics, Kyoto University > > kitagawa@kuis.kyoto-u.ac.jp > > From owner-ietf-fax@mail.imc.org Tue Mar 28 21:14:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01249 for ; Tue, 28 Mar 2000 21:14:32 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA13550 for ietf-fax-bks; Tue, 28 Mar 2000 17:41:11 -0800 (PST) Received: from jog.kuis.kyoto-u.ac.jp (jog.kuis.kyoto-u.ac.jp [130.54.22.113]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA13546 for ; Tue, 28 Mar 2000 17:41:09 -0800 (PST) Received: (from kitagawa@localhost) by jog.kuis.kyoto-u.ac.jp (8.8.8/8.8.8) id KAA04723; Wed, 29 Mar 2000 10:43:33 +0900 (JST) (envelope-from kitagawa) To: ietf-fax@imc.org Subject: Re: Addition to agenda.. References: From: KITAGAWA Takurou In-Reply-To: (rshockey@ix.netcom.com's message of "Tue, 28 Mar 2000 19:14:02 -0500") MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII Date: 29 Mar 2000 10:43:33 +0900 Message-ID: <3gsnxa1rga.fsf@jog.kuis.kyoto-u.ac.jp> Lines: 67 User-Agent: Semi-gnus/6.10.12 SEMI/1.13.4 (Terai) FLIM/1.12.7 (=?ISO-8859-4?Q?Y=FEzaki?=) Emacs/20.4 (i386-unknown-freebsd2.2.6) MULE/4.0 (HANANOEN) Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: rshockey@ix.netcom.com writes: > A few comments on this proposal: > > 1. E.164 -> DNS mapping works just as well as this proposal and scales > to the largest enterprise or telephone company. > > > EXACTLY .. THIS IS THE ENUM PROPOSAL IN THE IETF. I have mentioned about this in the previous reply, so please see it. > 2. Is there supposed to be an Internet-wide authority on the > "best" offramp for everyone to use? > > THIS IS THE TRIP ISSUE IN THE IPTEL WG.... With TRIP, gateway providors cannot have thier own local policies. > 3. Why HTTP instead of LDAP? Because HTTP is ubiquitous? > > YOU DONT USE HTTP, UNLESS YOU WANT TO HAVE THE SAME PROBLEMS THE IPP WG HAS HAD OVER THE YEARS. > > THE IETF IS VERY VERY STRICT THESE DAYS ON THE USE OF HTTP IN APPLICATION PROTOCOLS. I don't understand the reason. Please tell me your suggesting protocol. -- KITAGAWA Takurou Graduate School of Informatics, Kyoto University kitagawa@kuis.kyoto-u.ac.jp > > -Dan Wing > > > On 28 Mar 2000 23:29 +0900, KITAGAWA Takurou wrote: > > > > > tamura@toda.ricoh.co.jp writes: > > > > > Dear Colleagues, > > > > > > A person asked me that he would like to make a presentation > > > at our meeting about Fax-Gateway issue. > > > > > > He requests only 5 minutes, so Allocchio-san and I accepted it. > > > Before closing our meeting, he will do it. > > > > > > I do not know if his idea is good/suitable for our wg/ > > > useful or not. Because it is not based on SMTP. > > > > > > Anyway, he promised to me that he will circulte his detailed idea > > > in our ML, sooner or later. > > > > > > Regards, > > > -- > > > Hiroshi Tamura(tamura@toda.ricoh.co.jp) > > > > --------------------------------------------------------------------------- > > Directory Server for Internet Fax with HTTP and CGI > > > > Abstract > > > > A d From owner-ietf-fax@mail.imc.org Tue Mar 28 22:23:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02603 for ; Tue, 28 Mar 2000 22:23:03 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA19575 for ietf-fax-bks; Tue, 28 Mar 2000 18:48:39 -0800 (PST) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19568 for ; Tue, 28 Mar 2000 18:48:38 -0800 (PST) From: rshockey@ix.netcom.com Received: from smui1.atl.mindspring.net (smui1.atl.mindspring.net [207.69.200.121]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id VAA06493 for ; Tue, 28 Mar 2000 21:51:02 -0500 (EST) Received: by smui1.atl.mindspring.net id VAA0000020311; Tue, 28 Mar 2000 21:51:02 -0500 (EST) Date: Tue, 28 Mar 2000 21:51:02 -0500 To: ietf-fax@imc.org Subject: Agena Changes Message-ID: X-Originating-IP: 169.208.127.6 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: With TRIP, gateway providors cannot have thier own local policies. > 3. Why HTTP instead of LDAP? Because HTTP is ubiquitous? > > YOU DONT USE HTTP, UNLESS YOU WANT TO HAVE THE SAME PROBLEMS THE IPP WG HAS HAD OVER THE YEARS. > > THE IETF IS VERY VERY STRICT THESE DAYS ON THE USE OF HTTP IN APPLICATION PROTOCOLS. I don't understand the reason. The reason is that too many applications are trying to get through firewalls by simply using http and port 80. This is now considered a big NO NO. New uses of http in applications now require a seperate scheme and port. IPP was forced to go to ipp:// xxxx etc and use port 631 for its application. LDAP for query..its really your only choice. Please tell me your suggesting protocol. -- KITAGAWA Takurou Graduate School of Informatics, Kyoto University kitagawa@kuis.kyoto-u.ac.jp > > -Dan Wing > > From owner-ietf-fax@mail.imc.org Wed Mar 29 02:31:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17033 for ; Wed, 29 Mar 2000 02:31:04 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA08351 for ietf-fax-bks; Tue, 28 Mar 2000 23:05:24 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA08347 for ; Tue, 28 Mar 2000 23:05:23 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id XAA12533; Tue, 28 Mar 2000 23:07:18 -0800 (PST) Date: Tue, 28 Mar 2000 23:07:18 -0800 (PST) From: Dan Wing To: rshockey@ix.netcom.com cc: ietf-fax@imc.org Subject: Re: Addition to agenda.. In-Reply-To: Message-ID: <0003282306000.13999-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 28 Mar 2000 19:14 -0500, rshockey@ix.netcom.com wrote: > THE IETF IS VERY VERY STRICT THESE DAYS ON THE USE OF HTTP IN > APPLICATION PROTOCOLS. Yeah, but this proposal is really a layer-7 thing, in my view. It doesn't really involve the IETF as it doesn't do anything -- he's just looking up a mapping of E.164 -> email address using HTTP. Gosh, seems too much like a non-standardizable solution to me, really! -d From owner-ietf-fax@mail.imc.org Wed Mar 29 02:38:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17118 for ; Wed, 29 Mar 2000 02:38:36 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA08798 for ietf-fax-bks; Tue, 28 Mar 2000 23:11:46 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA08794 for ; Tue, 28 Mar 2000 23:11:45 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id XAA14787; Tue, 28 Mar 2000 23:13:39 -0800 (PST) Date: Tue, 28 Mar 2000 23:13:39 -0800 (PST) From: Dan Wing To: rshockey@ix.netcom.com cc: ietf-fax@imc.org Subject: Re: Addition to agenda.. In-Reply-To: <0003282306000.13999-100000@omega.cisco.com> Message-ID: <0003282308570.13999-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 28 Mar 2000 23:07 -0800, Dan Wing wrote: > On Tue, 28 Mar 2000 19:14 -0500, rshockey@ix.netcom.com wrote: > > > THE IETF IS VERY VERY STRICT THESE DAYS ON THE USE OF HTTP IN > > APPLICATION PROTOCOLS. > > Yeah, but this proposal is really a layer-7 thing, in my view. It doesn't > really involve the IETF as it doesn't do anything -- he's just looking up > a mapping of E.164 -> email address using HTTP. Gosh, seems too much like > a non-standardizable solution to me, really! [Actually, after thinking about it for another minute....] Informational may make a lot of sense for the proposal. The difficulty is in describing how to find the 'correct' HTTP server with the 'correct' information for each subscriber. ENUM solves this straight away ("ask your DNS server", which is expected to be configured correctly by your IS group), but the lookup-by-HTTP proposal leaves the "how do you find the HTTP server that knows the correct answers for you" as an open problem. That's hard to solve. But, again, it's useful as an Informational RFC; something else has to solve the more difficult problem of "how to find the HTTP server that knows the answer for ''you''". -Dan Wing From owner-ietf-fax@mail.imc.org Wed Mar 29 02:39:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17135 for ; Wed, 29 Mar 2000 02:39:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA08837 for ietf-fax-bks; Tue, 28 Mar 2000 23:14:35 -0800 (PST) Received: from jog.kuis.kyoto-u.ac.jp (jog.kuis.kyoto-u.ac.jp [130.54.22.113]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA08832 for ; Tue, 28 Mar 2000 23:14:30 -0800 (PST) Received: (from kitagawa@localhost) by jog.kuis.kyoto-u.ac.jp (8.8.8/8.8.8) id QAA05133; Wed, 29 Mar 2000 16:16:51 +0900 (JST) (envelope-from kitagawa) To: ietf-fax@imc.org Subject: Re: Agena Changes References: From: KITAGAWA Takurou In-Reply-To: (rshockey@ix.netcom.com's message of "Tue, 28 Mar 2000 21:51:02 -0500") MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII Date: 29 Mar 2000 16:16:50 +0900 Message-ID: <3gn1nip7od.fsf@jog.kuis.kyoto-u.ac.jp> Lines: 37 User-Agent: Semi-gnus/6.10.12 SEMI/1.13.4 (Terai) FLIM/1.12.7 (=?ISO-8859-4?Q?Y=FEzaki?=) Emacs/20.4 (i386-unknown-freebsd2.2.6) MULE/4.0 (HANANOEN) Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: rshockey@ix.netcom.com writes: > With TRIP, gateway providors cannot have thier own local policies. > > > 3. Why HTTP instead of LDAP? Because HTTP is ubiquitous? > > > > YOU DONT USE HTTP, UNLESS YOU WANT TO HAVE THE SAME PROBLEMS THE IPP WG HAS HAD OVER THE YEARS. > > > > THE IETF IS VERY VERY STRICT THESE DAYS ON THE USE OF HTTP IN APPLICATION PROTOCOLS. > > I don't understand the reason. > > The reason is that too many applications are trying to get through firewalls by simply using http and port 80. This is now considered a big NO NO. New uses of http in applications now require a seperate scheme and port. IPP was forced to go to ipp:// xxxx etc and use port 631 for its application. I don't think that such a change does not make firewalls more effective, but anyway, changing scheme-name and port# in this directory server is acceptable. -- KITAGAWA Takurou Graduate School of Informatics, Kyoto University kitagawa@kuis.kyoto-u.ac.jp > > LDAP for query..its really your only choice. > Please tell me your suggesting protocol. > > -- > KITAGAWA Takurou > Graduate School of Informatics, Kyoto University > kitagawa@kuis.kyoto-u.ac.jp > > > > > -Dan Wing > > > > From owner-ietf-fax@mail.imc.org Wed Mar 29 02:58:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17259 for ; Wed, 29 Mar 2000 02:58:28 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA09617 for ietf-fax-bks; Tue, 28 Mar 2000 23:29:02 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA09613 for ; Tue, 28 Mar 2000 23:29:00 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id XAA21676; Tue, 28 Mar 2000 23:30:19 -0800 (PST) Date: Tue, 28 Mar 2000 23:30:18 -0800 (PST) From: Dan Wing To: KITAGAWA Takurou , Richard Shockey cc: IETF Internet Fax WG Subject: Re: Agena Changes In-Reply-To: <3gn1nip7od.fsf@jog.kuis.kyoto-u.ac.jp> Message-ID: <0003282327390.13999-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 29 Mar 2000 16:16 +0900, KITAGAWA Takurou wrote: > rshockey@ix.netcom.com writes: > > > With TRIP, gateway providors cannot have thier own local policies. > > > > > 3. Why HTTP instead of LDAP? Because HTTP is ubiquitous? > > > > > > YOU DONT USE HTTP, UNLESS YOU WANT TO HAVE THE SAME PROBLEMS THE IPP WG HAS HAD OVER THE YEARS. > > > > > > THE IETF IS VERY VERY STRICT THESE DAYS ON THE USE OF HTTP IN APPLICATION PROTOCOLS. > > > > I don't understand the reason. > > > > The reason is that too many applications are trying to get through > > firewalls by simply using http and port 80. This is now considered a > > big NO NO. New uses of http in applications now require a seperate > > scheme and port. IPP was forced to go to ipp:// xxxx etc and use port > > 631 for its application. > > I don't think that such a change does not make firewalls more effective, > but anyway, changing scheme-name and port# in this directory server is > acceptable. Additionally, the lookup mechanism wouldn't be used between companies on the Internet so I don't think the issue with HTTP applies (and is also why I don't think this is really a protocol or interoperability issue between endpoints -- but may well be an interoperability issue between, say, fax machine manufacturers and HTTP-fronted databases). So, I don't think HTTP is a sticking point here at all. Richard, do you disagree? -Dan Wing From owner-ietf-fax@mail.imc.org Wed Mar 29 08:12:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20602 for ; Wed, 29 Mar 2000 08:12:20 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA26791 for ietf-fax-bks; Wed, 29 Mar 2000 04:44:22 -0800 (PST) Received: from pp-mx0.tokyo.spin.ad.jp (PP-mx0.Tokyo.Spin.AD.JP [165.76.52.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA26787 for ; Wed, 29 Mar 2000 04:44:21 -0800 (PST) Received: from localhost (dhcp-34-20.ietf.connect.com.au [169.208.34.20]) by pp-mx0.tokyo.spin.ad.jp (8.8.8+Spin/3.6W-JENS-stand2(10/10/99)) id VAA04863; Wed, 29 Mar 2000 21:46:40 +0900 (JST) To: dwing@cisco.com Cc: kitagawa@kuis.kyoto-u.ac.jp, rshockey@ix.netcom.com, ietf-fax@imc.org Subject: Re: Agena Changes From: tamura@toda.ricoh.co.jp Reply-To: tamura@toda.ricoh.co.jp In-Reply-To: <0003282327390.13999-100000@omega.cisco.com> References: <3gn1nip7od.fsf@jog.kuis.kyoto-u.ac.jp> <0003282327390.13999-100000@omega.cisco.com> X-Mailer: Mew version 1.94.1 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: <20000329214707M.adm@ifax.attnet.ne.jp> Date: Wed, 29 Mar 2000 21:47:07 +0900 (JST) X-Dispatcher: imput version 990905(IM130) Lines: 18 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Comment as one of implementers. > Additionally, the lookup mechanism wouldn't be used between companies on > the Internet so I don't think the issue with HTTP applies (and is also why > I don't think this is really a protocol or interoperability issue between > endpoints -- but may well be an interoperability issue between, say, fax > machine manufacturers and HTTP-fronted databases). Yes. Manufacturers always think of the interoperability, irrespective of proposals, although it may be bad sometimes. As a co-chair, Anyway, shall we listen to his proposal ? -- Hiroshi Tamura(tamura@toda.ricoh.co.jp) From owner-ietf-fax@mail.imc.org Wed Mar 29 08:14:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20620 for ; Wed, 29 Mar 2000 08:14:13 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA26749 for ietf-fax-bks; Wed, 29 Mar 2000 04:42:06 -0800 (PST) Received: from magic.kuis.kyoto-u.ac.jp (dhcp-32-75.ietf.connect.com.au [169.208.32.75]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA26742 for ; Wed, 29 Mar 2000 04:42:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by magic.kuis.kyoto-u.ac.jp (8.9.3/8.9.3) with ESMTP id VAA05302; Wed, 29 Mar 2000 21:42:31 +0900 (JST) (envelope-from fujikawa@real-internet.org) To: dwing@cisco.com Cc: ietf-fax@imc.org Subject: Re: Addition to agenda.. In-Reply-To: Your message of "Tue, 28 Mar 2000 23:13:39 -0800 (PST)" <0003282308570.13999-100000@omega.cisco.com> References: <0003282308570.13999-100000@omega.cisco.com> X-Mailer: Mew version 1.93 on XEmacs 20.4 (Emerald) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000329214230C.fujikawa@real-internet.org> Date: Wed, 29 Mar 2000 21:42:30 +0900 From: FUJIKAWA Kenji X-Dispatcher: imput version 990731(IM118) Lines: 39 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Dan; From: Dan Wing Subject: Re: Addition to agenda.. Date: Tue, 28 Mar 2000 23:13:39 -0800 (PST) > Informational may make a lot of sense for the proposal. The difficulty is > in describing how to find the 'correct' HTTP server with the 'correct' > information for each subscriber. > ENUM solves this straight away ("ask > your DNS server", which is expected to be configured correctly by your IS > group), but the lookup-by-HTTP proposal leaves the "how do you find the > HTTP server that knows the correct answers for you" as an open problem. > > That's hard to solve. > > But, again, it's useful as an Informational RFC; something else has to > solve the more difficult problem of "how to find the HTTP server that > knows the answer for ''you''". > First, a user makes a contract with a certain gateway provider, and then, is notified of directory server's addresses of the provider. Those directory servers tell gateways of the provider to the user. Uses of gateways have to be charged, since gateways use PSTN too. Our proposal gives a straghtforwad way for this. Authentication will be peformed by just client's IP address, or by SMTP with some authentication mechanism. Regards, --------------------------------------------------------------- FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan WWW: http://www.lab1.kuis.kyoto-u.ac.jp/~fujikawa/index-e.html TEL +81 75-753-5387 FAX +81 75-751-0482 E-mail fujikawa@real-internet.org From owner-ietf-fax@mail.imc.org Wed Mar 29 08:49:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20925 for ; Wed, 29 Mar 2000 08:49:12 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA27581 for ietf-fax-bks; Wed, 29 Mar 2000 05:20:01 -0800 (PST) Received: from elettra.trieste.it (SYNW10.elettra.trieste.it [140.105.2.12]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA27575 for ; Wed, 29 Mar 2000 05:19:51 -0800 (PST) Date: Wed, 29 Mar 2000 15:19:55 +0100 To: tamura@toda.ricoh.co.jp cc: dwing@cisco.com, kitagawa@kuis.kyoto-u.ac.jp, rshockey@ix.netcom.com, ietf-fax@imc.org In-Reply-To: <20000329214707M.adm@ifax.attnet.ne.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Re: Agena Changes Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Comment as one of implementers. > > Yes. > Manufacturers always think of the interoperability, irrespective of proposals, > although it may be bad sometimes. jUST ONE PERESONAL COMMENT: http (i'D SAY web ...) TENDS TO BE VERY "VOLATILE" AS DATABASE SOURCE... > > As a co-chair, > Anyway, shall we listen to his proposal ? Of course! But I' suggest that it is then discussed with ENUM people, because that is the correct WG. We can of course contribute with our suggestions, as we are already doing, but the correct WG is not ietf-fax. Claudio From owner-ietf-fax@mail.imc.org Wed Mar 29 10:10:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21690 for ; Wed, 29 Mar 2000 10:10:34 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA28953 for ietf-fax-bks; Wed, 29 Mar 2000 06:36:02 -0800 (PST) Received: from magic.kuis.kyoto-u.ac.jp (dhcp-32-75.ietf.connect.com.au [169.208.32.75]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28949 for ; Wed, 29 Mar 2000 06:36:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by magic.kuis.kyoto-u.ac.jp (8.9.3/8.9.3) with ESMTP id XAA05425; Wed, 29 Mar 2000 23:36:20 +0900 (JST) (envelope-from fujikawa@real-internet.org) To: Claudio.Allocchio@elettra.trieste.it Cc: ietf-fax@imc.org Subject: Re: Agena Changes In-Reply-To: Your message of "Wed, 29 Mar 2000 15:19:55 +0100" References: X-Mailer: Mew version 1.93 on XEmacs 20.4 (Emerald) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000329233619M.fujikawa@real-internet.org> Date: Wed, 29 Mar 2000 23:36:19 +0900 From: FUJIKAWA Kenji X-Dispatcher: imput version 990731(IM118) Lines: 34 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit From: Claudio Allocchio Subject: Re: Agena Changes Date: Wed, 29 Mar 2000 15:19:55 +0100 > > jUST ONE PERESONAL COMMENT: http (i'D SAY web ...) TENDS TO BE VERY > "VOLATILE" AS DATABASE SOURCE... > > > > > As a co-chair, > > Anyway, shall we listen to his proposal ? > > Of course! But I' suggest that it is then discussed with ENUM people, > because that is the correct WG. I made sure in the ENUM WG meeting that there is a case where local mapping E.164 -> URL (mail address) is required, and that this is out of scope of ENUM WG. The point is that ENUM is focused on global mapping and our proposal is focused on local mapping. Each gateway provider will want to have his own policy in an Internet fax envirionment. > We can of course contribute with our > suggestions, as we are already doing, but the correct WG is not ietf-fax. > --------------------------------------------------------------- FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan WWW: http://www.lab1.kuis.kyoto-u.ac.jp/~fujikawa/index-e.html TEL +81 75-753-5387 FAX +81 75-751-0482 E-mail fujikawa@real-internet.org From owner-ietf-fax@mail.imc.org Wed Mar 29 19:16:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26046 for ; Wed, 29 Mar 2000 19:16:33 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA09431 for ietf-fax-bks; Wed, 29 Mar 2000 15:54:20 -0800 (PST) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA09427 for ; Wed, 29 Mar 2000 15:54:19 -0800 (PST) From: rshockey@ix.netcom.com Received: from smui4.eng00.mindspring.net (smui4.eng00.mindspring.net [207.69.200.49]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id SAA10641 for ; Wed, 29 Mar 2000 18:56:44 -0500 (EST) Received: by smui4.eng00.mindspring.net id SAA0000000212; Wed, 29 Mar 2000 18:56:44 -0500 (EST) Date: Wed, 29 Mar 2000 18:56:44 -0500 To: ietf-fax@imc.org Subject: Agenda Changes Message-ID: X-Originating-IP: 169.208.127.6 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: jUST ONE PERESONAL COMMENT: http (i'D SAY web ...) TENDS TO BE VERY "VOLATILE" AS DATABASE SOURCE... > > As a co-chair, > Anyway, shall we listen to his proposal ? Of course! But I' suggest that it is then discussed with ENUM people, because that is the correct WG. We can of course contribute with our suggestions, as we are already doing, but the correct WG is not ietf-fax. Claudio ********* Well as ENUM co-chair I would certainly agree with that. :-)I think we are on a pretty straignt forward path to TN resolution to a variety of services and more inportatly directory oriented services. If you all recall I posted an ID on the use of ENUM in Fax a while back. The problem our WG has is with delegation issues...not the method of TN resolution itself. I agree with Dan and others that I mistook the use of HTTP in this proposal and I apologize for that ...its just my instinct to raise flags with HTTP considering the problems that IPP and by extention QUALDOCS had with that issue Rich Shockey From owner-ietf-fax@mail.imc.org Wed Mar 29 19:30:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26193 for ; Wed, 29 Mar 2000 19:30:20 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA09583 for ietf-fax-bks; Wed, 29 Mar 2000 16:07:05 -0800 (PST) Received: from pp-mx0.tokyo.spin.ad.jp (PP-mx0.Tokyo.Spin.AD.JP [165.76.52.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09579 for ; Wed, 29 Mar 2000 16:07:04 -0800 (PST) Received: from localhost (dhcp-34-20.ietf.connect.com.au [169.208.34.20]) by pp-mx0.tokyo.spin.ad.jp (8.8.8+Spin/3.6W-JENS-stand2(10/10/99)) id JAA12159; Thu, 30 Mar 2000 09:09:30 +0900 (JST) To: ietf-fax@imc.org Subject: Re: Agena Changes From: tamura@toda.ricoh.co.jp Reply-To: tamura@toda.ricoh.co.jp In-Reply-To: <20000329233619M.fujikawa@real-internet.org> References: <20000329233619M.fujikawa@real-internet.org> X-Mailer: Mew version 1.94.1 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: <20000330091001Z.adm@ifax.attnet.ne.jp> Date: Thu, 30 Mar 2000 09:10:01 +0900 (JST) X-Dispatcher: imput version 990905(IM130) Lines: 10 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Colleagues, It seems that there are opposite opinions to consider it in our WG. If you are in Adelaide and have some opinions about it, Please comment in our meeting today. -- Hiroshi Tamura(tamura@toda.ricoh.co.jp) From owner-ietf-fax@mail.imc.org Wed Mar 29 19:35:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26283 for ; Wed, 29 Mar 2000 19:35:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA09622 for ietf-fax-bks; Wed, 29 Mar 2000 16:10:16 -0800 (PST) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09618 for ; Wed, 29 Mar 2000 16:10:14 -0800 (PST) From: rshockey@ix.netcom.com Received: from smui4.eng00.mindspring.net (smui4.eng00.mindspring.net [207.69.200.49]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id TAA07768 for ; Wed, 29 Mar 2000 19:12:40 -0500 (EST) Received: by smui4.eng00.mindspring.net id TAA0000000672; Wed, 29 Mar 2000 19:12:38 -0500 (EST) Date: Wed, 29 Mar 2000 19:12:38 -0500 To: ietf-fax@imc.org Subject: ENUM is Fax [ was Agenda Changes] Message-ID: X-Originating-IP: 169.208.127.6 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Of course! But I' suggest that it is then discussed with ENUM people, > because that is the correct WG. I made sure in the ENUM WG meeting that there is a case where local mapping E.164 -> URL (mail address) is required, and that this is out of scope of ENUM WG. The point is that ENUM is focused on global mapping and our proposal is focused on local mapping. ****** Well I would still agrue that ENUM is a better resolution protocol even in local mapping environments. We've already had discussion on enterprise local dialing plan support its quite easy to accomodiate in the scheme of things. I would stongly argue that having 2 TN resolution protocols is a BAD idea. ************************ Each gateway provider will want to have his own policy in an Internet fax envirionment. ****** Policy, is of course, another issue. ************* > We can of course contribute with our > suggestions, as we are already doing, but the correct WG is not ietf-fax. Rich Shockey >