RE: profiles in AS2
[email protected] Fri, 16 Dec 2005 17:36:08 -0500
| Newsgroups | gmane.ietf.ediint |
|---|---|
| Message-ID | <OFCE443A98.257F4B4B-ON852570D9.0078B66A-852570D9.007C29A5@na.pg.com> |
This is a multipart message in MIME format. --=_alternative 007C283F852570D9_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I prefer Richard Bigelow's suggestion of an addition (or variant) to=20 Option 2 vs. negotiating during a session setup (which could be a=20 significant change to existing AS2 processes). An originator could send a = message to all its trading partners when its=20 capabilities change. This message would have headers only, no content,=20 and would be sent only to partners who are using AS2-Version 1.2 or=20 greater (indicating they support the Feature Header). This would ensure=20 that partners would be notified of new capabilities prior to the=20 originator using the new capability.=20 As a fail-safe, all partners should send the Feature Header to partners=20 who are using AS2-Version 1.2 or greater with every message, in case the=20 Header-only message is lost or not processed. This would require software implementations to keep state information=20 (probably in a partner profile) recording the AS2-Version, and indication=20 of which Features each partner supports. Do other AS2 software vendors object to Option 2 (with AS2-Version 1.2)? Can anyone see any backward compatibility problems with Option 2 (using=20 the AS2-Version 1.2 indicator) in communicating with version 1.0 or 1.1=20 products? Would existing AS2 products (or products already supporting Option 2 in=20 test) handle a Header-only message? best regards, John Duker Procter & Gamble "Gijsbert in 't Veld" <[email protected]> Sent by: [email protected] 12/16/2005 03:43 AM =20 To: "Kyle Meadors" <[email protected]>, <[email protected]= rg> cc:=20 Subject: RE: profiles in AS2 I'm in favor of the features header in combination with the version=20 indicator, but the features (capabilities) should always be negotiated=20 during session setup. For each capability, the lowest "level" wins. So if=20 A sets up a connection with B and requests "Multiple attachments=3DYes" the= n=20 B could say "Multiple attachments=3DNo". The result will then be "Multiple = attachments=3DNo". =20 Also, the mininum AS2 protocol version supported should be 1.0. All the=20 AS2 implementions should be backwards compatible. Detecting an older=20 version then the one that will support feature negotiation always means=20 that there are no features to be negotiated. =20 That way it's very flexible. This is how it's done in other major=20 protocols as well (for example OFTP). =20 Best, Gijsbert in 't Veld Covast CTO --------------------------------------------------------------------------= ---------------------------------------------------------------------------= ------ From: [email protected] [mailto:[email protected]= ] On Behalf Of Kyle Meadors Sent: Thursday, December 15, 2005 11:21 PM To: [email protected] Subject: RE: profiles in AS2 Not a lot of comments on this thread. But to summarize? =20 3 in favor of Option 2 (Features header) and use of AS2?Version 1.2=20 1 in favor Option 3 where filtering is done on a message =20 Still does not fully address the initial start?up conditions as Richard=20 pointed out, but perhaps that just can not be done without some manual=20 setup. =20 Since this EDIINT WG will likely be closing relatively soon, I hope we can = get some more to weigh in on this. Do others object to Option 2 (with=20 AS2?Version 1.2)? =20 For those AS2 vendors supporting Option 2, would this impact your product, = including those deployed in existing supply chains? Are their significant=20 backward compatibility problems with this choice? =20 Kyle Meadors DGI From: Tim McCarthy [mailto:[email protected]]=20 Sent: Wednesday, December 07, 2005 9:14 AM To: Kyle Meadors; [email protected] Subject: RE: profiles in AS2 =20 Seems to me that a combination of features 2 and 4 would provide=20 everything we'd need. =20 From: [email protected] [mailto:[email protected]= ] On Behalf Of Richard Bigelow Sent: Tuesday, December 06, 2005 5:07 PM To: Kyle Meadors; [email protected] Subject: RE: profiles in AS2 =20 These are my comments. Option 2 is preferred. This memo essentially=20 supports John Duker's memo of Dec. 5, Features Profile in AS2. =20 1. This option requires that implementers of feature 1.n also implement=20 all earlier features. Is that reasonable? What if 1.5 is difficult and=20 many vendors don't want to do it, but many want to support 1.6? Not=20 recommended. =20 2. The features header allows the partner A receiving the message to know = the other partner's (B's) capabilities. So when A sends to B, A knows=20 what is allowed. A can also check B's AS2-version; 1.1 does not allow any = of the controlled features, but does allow compression. A should update=20 some state for every message received from B. B might stop supporting=20 some feature. Recommended. =20 A possible variant of (2) is that a partner could send some message to all = its trading partners when its capabilities change. This message would=20 have headers only, no content. It might be useful to send this=20 capabilities message to partners that would rarely receive normal=20 messages. =20 3. This option allows receivers to ignore messages they don't understand,=20 and to detect those messages without looking for unknown headers. But it=20 does not provide a mechanism for the sender to know whether a receiver can = receive the message. Suppose we had done compression this way. A could=20 send a compressed file to B, and B could ignore it based on the feature=20 header, but then the file is lost. B could return a new MDN code=20 indicating unsupported-feature, and A could then send the uncompressed=20 file, in this example. In other cases, A would have to use some other=20 mechanism. A could remember that B rejected the file and not try that=20 feature again, but how would A know if B upgraded and can now support the=20 feature? The original intent of the features header was that the sender=20 could know in advance if the receiver supports the feature. 3 is not=20 recommended. =20 4. Before sending a message to B, A should ask B for B's capabilities, and = check if B supports the feature. Since B might stop supporting a feature, = A should ask each time. This is ok for rare messages, like CEM, but not=20 for common ones, like Multiple Attachments. Not recommended. =20 None of these protocols fully addresses the initial case. Before any=20 messages are exchanged, how do the partners know each other's=20 capabilities? Each partner must assume that the other supports only the=20 basic 1.0 AS2 protocol. Hopefully, they will be able to exchange normal=20 messages, which will contain at least the 1.2 version header. They can=20 then use option 2 to discover each other capabilities. This probably=20 works for most features. For CEM, either they must first exchange test=20 messages that are unencrypted and unsigned to establish CEM capability, or = exchange initial certificates manually. =20 Alternatively, the partners would configure each other manually the first=20 time. Thereafter, they would be automatically updated on each other's=20 capabilities. =20 Richard Bigelow Inovis [email protected] From: [email protected] [mailto:[email protected]= ] On Behalf Of Kyle Meadors Sent: Thursday, December 01, 2005 9:04 AM To: [email protected] Subject: profiles in AS2 =20 I am needing the opinion of the AS2 community on the use of a feature=20 profiles within AS2. Back in 2002, compression was added as an extra=20 feature. Using "AS2?Version: 1.1" in a message indicated the UA could=20 support compression even if the actual message did not contain the=20 compressed envelope. This assisted implementers in knowing if their=20 trading partners could support compression.=20 =20 Moving to the present, users are requesting new features. These include=20 I?Ds for Reliability (from GS1), Multiple?Attachments (oil & gas users)=20 and Certificate Exchange Messaging (Wal?mart, P&G and others GS1=20 companies). Given AS2's adoption, I am sure there will be others in the=20 future.=20 =20 My question to those on this elist is how to do move forward with new=20 features. What do we do to insure only those who support a feature receive = it (e.g., only sending CEM message to trading partners who support that=20 profile)? Also, can anything be done to insure backward compatibility to=20 keep new Feature Header messages from being sent to & breaking older,=20 existing implementations (e.g. older implementation errors gracefully when = getting an unrecognized MA message).=20 =20 Here are some options. I would like to hear your thoughts on what is best=20 or other ideas.=20 =20 1. Use AS2?Version header to indicate UA support of profiles (e.g. 1.2=20 indicates CEM, 1.3 indicates CEM, Reliability). Works like compression=20 (e.g. "1.2" indicates capability of CEM but not an actual CEM message). =20 2. Use a new header, e.g. EDIINT?Features. The features header shows all=20 features supported by UA (e.g. EDIINT?Features: CEM, multiple?attachment)=20 but like AS2?Version does not indicate every message contains profile. =20 3. Use a new header for each feature which is present ONLY in the message=20 using that feature. For example, "CEM?Profile" for CEM messages. This=20 could allow receiving UA to filter in only profiles it recognizes. =20 4. Create a "Capability Query" AS2 Message which returns a Capability MDN. = MDN indicates what features receiving UA can support. =20 =20 Kyle Meadors Principal, Test Process Drummond Group Inc. 615.212.0826 =20 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.10/189 - Release Date:=20 11/30/2005 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.12/193 - Release Date: 12/6/2005 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.0/203 - Release Date: 12/15/2005 --=_alternative 007C283F852570D9_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <br><font size=3D2 face=3D"sans-serif">I prefer Richard Bigelow's suggestio= n of an addition (or variant) to Option 2 vs. negotiating during a session = setup (which could be a significant change to existing AS2 processes). </fo= nt><font size=3D2 face=3D"Arial"> An originator could send a message t= o all its trading partners when its capabilities change. This message= would have headers only, no content, and would be sent only to partners wh= o are using AS2-Version 1.2 or greater (indicating they support the Feature= Header). This would ensure that partners would be notified of new capabili= ties prior to the originator using the new capability. </font> <br> <br><font size=3D2 face=3D"Arial">As a fail-safe, all partners should send = the Feature Header to partners who are using AS2-Version 1.2 or greater wit= h every message, in case the Header-only message is lost or not processed.<= /font> <br> <br><font size=3D2 face=3D"Arial">This would require software implementatio= ns to keep state information (probably in a partner profile) recording the = AS2-Version, and indication of which Features each partner supports.</font> <br> <br><font size=3D2 face=3D"Arial"><b>Do other AS2 software vendors object t= o Option 2 (with AS2-Version 1.2)?</b></font> <br> <br><font size=3D2 face=3D"Arial"><b>Can anyone see any backward compatibil= ity problems with Option 2 (using the AS2-Version 1.2 indicator) in communi= cating with version 1.0 or 1.1 products?</b></font> <br> <br><font size=3D2 face=3D"Arial"><b>Would existing AS2 products (or produc= ts already supporting Option 2 in test) handle a Header-only message?</b></= font> <br> <br><font size=3D2 face=3D"Arial">best regards,</font> <br><font size=3D2 face=3D"Arial">John Duker</font> <br><font size=3D2 face=3D"Arial">Procter & Gamble</font> <br> <br> <table width=3D100%> <tr valign=3Dtop> <td> <td><font size=3D1 face=3D"sans-serif"><b>"Gijsbert in 't Veld" &= lt;[email protected]></b></font> <br><font size=3D1 face=3D"sans-serif">Sent by: [email protected].= org</font> <p><font size=3D1 face=3D"sans-serif">12/16/2005 03:43 AM</font> <br> <td><font size=3D1 face=3D"Arial"> </font> <br><font size=3D1 face=3D"sans-serif"> To: &nbs= p; "Kyle Meadors" <[email protected]&= gt;, <[email protected]></font> <br><font size=3D1 face=3D"sans-serif"> cc: &nbs= p; </font> <br><font size=3D1 face=3D"sans-serif"> Subject:= RE: profiles in AS2</font></table> <br><font size=3D2 color=3D#000080 face=3D"Arial">I'm in favor of the featu= res header in combination with the version indicator, but the features (cap= abilities) should always be negotiated during session setup. For each capab= ility, the lowest "level" wins. So if A sets up a connection with B and req= uests "Multiple attachments=3DYes" then B could say "Multiple attachments= =3DNo". The result will then be "Multiple attachments=3DNo".</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Also, the mininum AS2 pro= tocol version supported should be 1.0. All the AS2 implementions should be = backwards compatible. Detecting an older version then the one that will sup= port feature negotiation always means that there are no features to be nego= tiated.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">That way it's very flexib= le. This is how it's done in other major protocols as well (for example OFT= P).</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Best,</font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Gijsbert in 't Veld</font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Covast CTO</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font><font size= =3D2 face=3D"sans-serif">--------------------------------------------------= ---------------------------------------------------------------------------= ------------------------------</font> <br><font size=3D2 face=3D"Tahoma"><b>From:</b> [email protected].= org [mailto:[email protected]] <b>On Behalf Of </b>Kyle Meador= s<b><br> Sent:</b> Thursday, December 15, 2005 11:21 PM<b><br> To:</b> [email protected]<b><br> Subject:</b> RE: profiles in AS2</font> <br><font size=3D3 face=3D"Times New Roman"> </font><font size=3D2 col= or=3D#000080 face=3D"Arial">Not a lot of comments on this thread. But to su= mmarize…</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">3 in favor of Option 2 (F= eatures header) and use of AS2–Version 1.2 </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">1 in favor Option 3 where= filtering is done on a message</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Still does not fully addr= ess the initial start–up conditions as Richard pointed out, but perha= ps that just can not be done without some manual setup.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Since this EDIINT WG will= likely be closing relatively soon, I hope we can get some more to weigh in= on this. Do others object to Option 2 (with AS2–Version 1.2)?</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">For those AS2 vendors sup= porting Option 2, would this impact your product, including those deployed = in existing supply chains? Are their significant backward compatibility pro= blems with this choice?</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Kyle Meadors</font> <br><font size=3D2 color=3D#000080 face=3D"Arial">DGI</font> <div align=3Dcenter> <br> <hr></div> <br><font size=3D2 face=3D"Tahoma"><b>From:</b> Tim McCarthy [mailto:TMcCar= [email protected]] <b><br> Sent:</b> Wednesday, December 07, 2005 9:14 AM<b><br> To:</b> Kyle Meadors; [email protected]<b><br> Subject:</b> RE: profiles in AS2</font> <br><font size=3D3 face=3D"Times New Roman"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Seems to me that a combin= ation of features 2 and 4 would provide everything we'd need.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <div align=3Dcenter> <br> <hr></div> <br><font size=3D2 face=3D"Tahoma"><b>From:</b> [email protected].= org [mailto:[email protected]] <b>On Behalf Of </b>Richard Big= elow<b><br> Sent:</b> Tuesday, December 06, 2005 5:07 PM<b><br> To:</b> Kyle Meadors; [email protected]<b><br> Subject:</b> RE: profiles in AS2</font> <br><font size=3D3 face=3D"Times New Roman"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">These are my comments. &n= bsp;Option 2 is preferred. This memo essentially supports John Duker'= s memo of Dec. 5, Features Profile in AS2.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">1. This option requires t= hat implementers of feature 1.n also implement all earlier features. = Is that reasonable? What if 1.5 is difficult and many vendors don't w= ant to do it, but many want to support 1.6? Not recommended.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">2. The features hea= der allows the partner A receiving the message to know the other partner's = (B's) capabilities. So when A sends to B, A knows what is allowed. &n= bsp;A can also check B's AS2-version; 1.1 does not allow any of the control= led features, but does allow compression. A should update some state = for every message received from B. B might stop supporting some featu= re. Recommended.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">A possible variant of (2)= is that a partner could send some message to all its trading partners when= its capabilities change. This message would have headers only, no co= ntent. It might be useful to send this capabilities message to partne= rs that would rarely receive normal messages.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">3. This option allows rec= eivers to ignore messages they don't understand, and to detect those messag= es without looking for unknown headers. But it does not provide a mec= hanism for the sender to know whether a receiver can receive the message. &= nbsp;Suppose we had done compression this way. A could send a compres= sed file to B, and B could ignore it based on the feature header, but then = the file is lost. B could return a new MDN code indicating unsupporte= d-feature, and A could then send the uncompressed file, in this example. &n= bsp;In other cases, A would have to use some other mechanism. A could= remember that B rejected the file and not try that feature again, but how = would A know if B upgraded and can now support the feature? The origi= nal intent of the features header was that the sender could know in advance= if the receiver supports the feature. 3 is not recommended.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">4. Before sending a messa= ge to B, A should ask B for B's capabilities, and check if B supports the f= eature. Since B might stop supporting a feature, A should ask each ti= me. This is ok for rare messages, like CEM, but not for common ones, = like Multiple Attachments. Not recommended.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">None of these protocols f= ully addresses the initial case. Before any messages are exchanged, h= ow do the partners know each other's capabilities? Each partner must = assume that the other supports only the basic 1.0 AS2 protocol. Hope= fully, they will be able to exchange normal messages, which will contain at= least the 1.2 version header. They can then use option 2 to discover= each other capabilities. This probably works for most features. &nbs= p;For CEM, either they must first exchange test messages that are unencrypt= ed and unsigned to establish CEM capability, or exchange initial certificat= es manually.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Alternatively, the partne= rs would configure each other manually the first time. Thereafter, th= ey would be automatically updated on each other's capabilities.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D1 color=3D#808080 face=3D"Verdana">Richard Bigelow<br> Inovis</font><font size=3D1 color=3Dblue face=3D"Verdana"><u><br> </u></font><a href=3Dmailto:[email protected]><font size=3D1 color= =3Dblue face=3D"Verdana"><u>[email protected]</u></font></a> <div align=3Dcenter> <br> <hr></div> <br><font size=3D2 face=3D"Tahoma"><b>From:</b> [email protected].= org [mailto:[email protected]] <b>On Behalf Of </b>Kyle Meador= s<b><br> Sent:</b> Thursday, December 01, 2005 9:04 AM<b><br> To:</b> [email protected]<b><br> Subject:</b> profiles in AS2</font> <br><font size=3D3 face=3D"Times New Roman"> </font> <br><font size=3D2 face=3D"Arial">I am needing the opinion of the AS2 commu= nity on the use of a feature profiles within AS2. Back in 2002, compression= was added as an extra feature. Using "AS2–Version: 1.1" in= a message indicated the UA could support compression even if the actual me= ssage did not contain the compressed envelope. This assisted implementers i= n knowing if their trading partners could support compression.</font><font = size=3D3 face=3D"Times New Roman"> </font><font size=3D2 face=3D"Arial"><br> </font><font size=3D3 face=3D"Times New Roman"> </font><font size=3D2= face=3D"Arial"><br> Moving to the present, users are requesting new features. These include I&#= 8211;Ds for Reliability (from GS1), Multiple–Attachments (oil & g= as users) and Certificate Exchange Messaging (Wal–mart, P&G and o= thers GS1 companies). Given AS2's adoption, I am sure there will be others = in the future.</font><font size=3D3 face=3D"Times New Roman"> </font><font = size=3D2 face=3D"Arial"><br> </font><font size=3D3 face=3D"Times New Roman"> </font><font size=3D2= face=3D"Arial"><br> My question to those on this elist is how to do move forward with new featu= res. What do we do to insure only those who support a feature receive it (e= .g., only sending CEM message to trading partners who support that profile)= ? Also, can anything be done to insure backward compatibility to keep new F= eature Header messages from being sent to & breaking older, existing im= plementations (e.g. older implementation errors gracefully when getting an = unrecognized MA message).</font><font size=3D3 face=3D"Times New Roman"> </= font><font size=3D2 face=3D"Arial"><br> </font><font size=3D3 face=3D"Times New Roman"> </font><font size=3D2= face=3D"Arial"><br> Here are some options. I would like to hear your thoughts on what is best o= r other ideas.</font><font size=3D3 face=3D"Times New Roman"> </font><font = size=3D2 face=3D"Arial"><br> </font> <br><font size=3D2 face=3D"Arial">1. Use AS2–Version header to indica= te UA support of profiles (e.g. 1.2 indicates CEM, 1.3 indicates CEM, Relia= bility). Works like compression (e.g. "1.2" indicates capability of CEM but= not an actual CEM message).</font> <br><font size=3D2 face=3D"Arial"> </font> <br><font size=3D2 face=3D"Arial">2. Use a new header, e.g. EDIINT–Fe= atures. The features header shows all features supported by UA (e.g. EDIINT= –Features: CEM, multiple–attachment) but like AS2–Version= does not indicate every message contains profile.</font> <br><font size=3D2 face=3D"Arial"> </font> <br><font size=3D2 face=3D"Arial">3. Use a new header for each feature whic= h is present ONLY in the message using that feature. For example, "CEM̵= 1;Profile" for CEM messages. This could allow receiving UA to filter in onl= y profiles it recognizes.</font> <br><font size=3D2 face=3D"Arial"> </font> <br><font size=3D2 face=3D"Arial">4. Create a "Capability Query" AS2</font>= <font size=3D2 color=3D#000080 face=3D"Arial"> </font><font size=3D2 face= =3D"Arial">Message which returns a Capability MDN. MDN indicates what featu= res</font><font size=3D2 color=3D#000080 face=3D"Arial"> </font><font size= =3D2 face=3D"Arial">receiving UA can support.</font> <br><font size=3D2 face=3D"Arial"> </font> <br><font size=3D2 face=3D"Arial"> </font> <br><font size=3D2 face=3D"Arial">Kyle Meadors</font> <br><font size=3D2 face=3D"Arial">Principal, Test Process</font> <br><font size=3D2 face=3D"Arial">Drummond Group Inc.</font> <br><font size=3D2 face=3D"Arial">615.212.0826</font> <br><font size=3D3 face=3D"Times New Roman"> </font> <p> <p><font size=3D2 face=3D"Times New Roman">--<br> No virus found in this outgoing message.<br> Checked by AVG Free Edition.<br> Version: 7.1.362 / Virus Database: 267.13.10/189 - Release Date: 11/30/2005= </font> <p> <p><font size=3D2 face=3D"Times New Roman">--<br> No virus found in this incoming message.<br> Checked by AVG Free Edition.<br> Version: 7.1.371 / Virus Database: 267.13.12/193 - Release Date: 12/6/2005<= /font> <p> <p><font size=3D2 face=3D"Times New Roman">--<br> No virus found in this outgoing message.<br> Checked by AVG Free Edition.<br> Version: 7.1.371 / Virus Database: 267.14.0/203 - Release Date: 12/15/2005<= /font> <p> <p> --=_alternative 007C283F852570D9_=--