Subject: Re: sasl-rfc2222bis review notes [long]

From: Rob Siemborski <[email-masked]>
Date: Mon, 1 Mar 2004 11:31:23 -0500 (EST)

On Mon, 1 Mar 2004, Alexey Melnikov wrote:

> >We should extend this to also cover things other than just TLS (e.g. a
> >compression layer, separate from either TLS or SASL).
> >
> >For example:
> >
> >If other transport or session layers (such as a Transport Layer Security
> >layer or a compression layer) in addition to the SASL security layer are
> >allowed to be negotiated by the protocol....
> >
> I don't think a protocol profile can reasonably define layering of
> multiple things when at least one of them is not known when the protocol
> profile is written.
> So I would rather not change the description.

Certainly if the existance of such a layer isn't know, you can't say where
it fits.  However, any known layers need to be documented for interop to
be ensured.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 02 Mar 2004 07:59:20 +0900

[This replies deals with two more comments from Kurt].

>>4.    Authentication mechanisms
>>
>>  SASL mechanisms are named by strings, from 1 to 20 characters in
>>  length, consisting of ASCII [ASCII] upper-case letters, digits,
>>  hyphens, and/or underscores.  SASL mechanism names must be registered
>>  with the Internet Assigned Numbers Authority (IANA). IETF standards
>>  track documents may direct the IANA to reserve a portion of the SASL
>>  mechanism namespace and may specify different registration criteria
>>  for the reserved portion; the GSSAPI mechanism specification
>>  [SASL-GSSAPI] does this.
>>    
>>
>
>The above sentence should be moved in IANA considerations section.
>
I think it already does:

8.2.  Registration procedure

...

There is no naming convention for SASL mechanisms; any name that
conforms to the syntax of a SASL mechanism name can be registered.
An IETF Standards Track document may reserve a portion of the SASL
mechanism namespace ("family of SASL mechanisms") for its own use,
amending the registration rules for that portion of the namespace.
Each family of SASL mechanisms MUST be identified by a prefix.

>>9.   Security considerations
>>
>>  Security issues are discussed throughout this memo.
>>
>>  The mechanisms that support integrity protection are designed such
>>  that the negotiation of the security layer and authorization identity
>>  is integrity protected.
>>    
>>
>
>This statement seems a bit circular.
>
>Also, "integrity protection" was defined as providing the capability
>to detection unauthorized changes to data transfered by the security
>layer.  However this uses the term implies that the authentication
>exchange, including layer negotiation is protected.  This is problematic.
>
I think the text should read:

The mechanisms that support integrity protection should be designed such ...

(I've changed "are" to "should be")

>If we look at DIGEST-MD5, which does offer a security layer
>with "integrity protection", we find a mechanism which does
> 
>
I assume you meant "does not".

>provide full integrity protection over the authentication
>exchange itself.
>
It doesn't protect the whole authentication exchange, but it protects 
both security layer negotiation and the authorization id.

>I think we need to a bit more precise with our terminology.  To
>avoid having to define a SASL-specific terminology, I strongly
>recommend we try to use RFC 2828 based terminology.
>
I think we should check if the SASL terminology in use now doesn't 
contradict RFC 2828.
This assumes that the document is updated to reference RFC 2828. I 
personally don't mind (if there are no major inconsistencies), but the 
WG has to give a feedback if this would be considered a good idea.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 02 Mar 2004 09:15:56 +0900

>it fits.  However, any known layers need to be documented for interop to
There is compression support in TLS now. Don't tell me you were talking 
about IMAP COMPRESS ;-).

My point is that if a new layer is invented later on, it has to document 
interaction with SASL security layer and TLS.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 02 Mar 2004 08:02:59 +0900

Kurt D. Zeilenga wrote:

>>  The Simple Authentication and Security Layer (SASL) provides a method
>>  for adding authentication support with an optional security layer to
>>  connection-based protocols.
>>    
>>
>
>As used here, the word "optional" implies that protocols MAY
>include security layer support.
>
In theory a protocol profile can disallow usage of a SASL security layer.

>Suggest this be reworded
>
>	The Simple Authentication and Security Layer (SASL) is a
>	framework for providing authentication and data security
>	services in connection-based protocols.
>
I like that.

>>                               It also describes a structure for
>>  authentication mechanisms.  The result is an abstraction layer
>>  between protocols and authentication mechanisms such that any SASL-
>>  compatible authentication mechanism can be used with any SASL-
>>  compatible protocol.
>>
>>  This document describes how a SASL authentication mechanism is
>>  structured, describes how a protocol adds support for SASL, defines
>>  the protocol for carrying a security layer over a connection, and
>>  defines the EXTERNAL SASL authentication mechanism.
>>    
>>
>
>It might be better to transpose EXTERNAL and SASL here.
>
Done.

>>2.    Organization of this document
>>
>>2.1.  How to read this document
>>
>>  This document is written to serve several different audiences,
>>  protocol designers using this specification to support authentication
>>  in their protocol, mechanism designers that define new SASL
>>  mechanisms, and implementors of clients or servers for those
>>  protocols using this specification.
>>    
>>
>
>I suggest using a bullet list for the above.
>
Sounds good.

>
>
>...
>
>>2.2.  Conventions used in this document
>>
>>  In examples, "C:" and "S:" indicate lines sent by the client and
>>  server respectively.
>>
>>  The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
>>  in this document are to be interpreted as defined in "Key words for
>>  use in RFCs to Indicate Requirement Levels" [KEYWORDS].
>>
>>  Character names in this document use the notation for code points and
>>  names from the Unicode Standard [Unicode].  For example, the letter
>>  "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
>>
>>  This document uses terms "integrity protection" and "confidentiality
>>  protection".  The former references to a security layer that is able
>>  to detect data modification by using some kind of hash.  However,
>>    
>>
>
>I suggest the "by using some kind of hash" qualification be dropped.   
>The term "integrity protection" applies to any layer which is capable
>of detecting data modification (regardless of whether it using some
>kind of hash or not).  I suggest:
>
>    The term "integrity protection" refers to a security layer         
>    designed to detect unauthorized data modification.
>
Ok
...

>>  authentication mechanism to be defined once, making it usable by any
>>  SASL protocol profile.  In many implementations, the same SASL
>>  mechanism code is used for multiple protocols.
>>    
>>
>
>Add another (see above) subsection which
>
>X.Y. Relationship to other documents
>
>    This document obsoletes RFC 2222.  It replaces all portions of
>    RFC 2222 excepting sections 7.1 (Kerberos version 4 mechanism),
>    7.2 (GSSAPI mechanism), 7.3 (S/Key mechanism).  The Kerberos
>    version 4 (KERBEROS_IV) and S/Key (SKEY) mechanisms are now        
>    viewed as obsolete.  The GSSAPI mechanism is now separately 
>    specified [SASL-GSSAPI].
>
I've added this as "Appendix B". The detailed list of changes in now 
Appendix C.

>>  Procedures for registering new SASL mechanisms are given in section 8.
>>
>>  The "sasl-mech" production below defines the syntax of a SASL
>>  mechanism name.  This uses the Augmented Backus-Naur Form (ABNF)
>>  notation as specified in [ABNF] and the ABNF core rules as specified
>>  in Appendix A of the ABNF specification [ABNF].
>>
>>  sasl-mech    = 1*20mech-char
>>  mech-char    = %x41-5A / DIGIT / "-" / "_"
>>                 ; mech names restricted to ASCII uppercase letters,
>>                 ; digits, "-" and "_"
>>
>>    
>>
>
>I suggest this comment be replaced with:
>        ; mech-char is restricted to "A"-"Z", "0"-"9", "-", and "_"
>        : from ASCII character set.
>
Done

>...
>
>>5.2.  Mechanism profile guidelines
>>
>>  Designers of new SASL mechanism should be aware of the following
>>  issues:
>>
>>  1) Authorization identity.
>>    
>>
>
>Remove the "."
>
Ok.

>>6.1.1.  Client sends data first examples
>>
>>  The following are two examples of an SECURID authentication [SASL-
>>  SECURID] in the SMTP protocol [SMTP].  In the first example below,
>>  the client is trying fast reauthentication by sending the initial
>>  response:
>>
>>     S: 220-smtp.example.com ESMTP Server
>>     C: EHLO client.example.com
>>     S: 250-smtp.example.com Hello client.example.com, pleased to meet you
>>    
>>
>
>This line is too long.  Suggest you s/Hello.*/Welcome client.example.com/
>
Done.

>>     S: 250-AUTH GSSAPI SECURID
>>     S: 250 DSN
>>     C: AUTH SECURID AG1hZ251cwAxMjM0NTY3OAA=
>>     S: 235 Authentication successful
>>
>>  The example below is almost identical to the previous, but here the
>>  client chooses not to use the initial response parameter.
>>
>>     S: 220-smtp.example.com ESMTP Server
>>     C: EHLO client.example.com
>>     S: 250-smtp.example.com Hello client.example.com, pleased to meet you
>>    
>>
>
>This line is too long.
>
Done.

>>     S: 250-AUTH GSSAPI SECURID
>>     S: 250 DSN
>>     C: AUTH SECURID
>>     S: 334
>>     C: AG1hZ251cwAxMjM0NTY3OAA=
>>     S: 235 Authentication successful
>>
>>     Section 7.2 contains an additional example.
>>    
>>
>
>Indention is off here.
>
Thanks.

>
>Also note that 7.2 provides two examples as does 6.2.1.
>So, this should read:
>	Additonal examples can be found in sections 6.2.1 and 7.2.
>
Changed.

>>     C: <stream:stream
>>         xmlns='jabber:client'
>>         xmlns:stream='http://etherx.jabber.org/streams'
>>         to='example.com'
>>         version='1.0'>
>>     S: <stream:stream
>>         xmlns='jabber:client'
>>         xmlns:stream='http://etherx.jabber.org/streams'
>>         id='c2s_234'
>>         from='example.com'
>>         version='1.0'>
>>     S: <stream:features>
>>          <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
>>            <mechanism>DIGEST-MD5</mechanism>
>>            <mechanism>CRAM-MD5</mechanism>
>>          </mechanisms>
>>        </stream:features>
>>     C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
>>              mechanism='DIGEST-MD5'/>
>>     S: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
>>        cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi
>>    
>>
>
>This line is too long...
>
Fixed.

>>        LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg==
>>        </challenge>
>>     C: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
>>        dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i
>>        T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw
>>        MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i
>>        LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo
>>        YXJzZXQ9dXRmLTgK
>>        </response>
>>     S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
>>        cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
>>        </success>
>>
>>     The example below is almost identical to the previous, but here
>>     the server chooses not to use the additional data with success.
>>
>>     C: <stream:stream
>>         xmlns='jabber:client'
>>         xmlns:stream='http://etherx.jabber.org/streams'
>>         to='example.com'
>>         version='1.0'>
>>     S: <stream:stream
>>         xmlns='jabber:client'
>>         xmlns:stream='http://etherx.jabber.org/streams'
>>         id='c2s_234'
>>         from='example.com'
>>         version='1.0'>
>>     S: <stream:features>
>>          <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
>>            <mechanism>DIGEST-MD5</mechanism>
>>            <mechanism>CRAM-MD5</mechanism>
>>          </mechanisms>
>>        </stream:features>
>>     C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
>>              mechanism='DIGEST-MD5'/>
>>     S: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
>>        cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi
>>    
>>
>
>This line is too long.
>
Fixed.

>...
>  
>
>>  Non-terminals referenced but not defined below are as defined by
>>  [UTF-8].
>>    
>>
>
>I suggest the non-terminal productions be directly incorporated
>into this document.
>
I actually disagree.
If there is an update to UTF-8, I wouldn't like to waste additional time 
trying to synchronize the two.

>>  The "extern-init-resp" rule below defines the initial response sent
>>  from client to server.
>>
>>  extern-init-resp  = *( UTF8-char-no-nul )
>>
>>  UTF8-char-no-nul  = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
>>
>>  UTF8-1-no-nul     = %x01-7F
>>
>>
>>7.2.  Example
>>
>>...
>>
>>  The following example is almost identical to the one above, but the
>>  client doesn't use proxy authentication.
>>    
>>
>
>s/use/request/
>
Changed.

>>     S: 220 smtp.example.com ESMTP server ready
>>     C: EHLO jgm.example.com
>>     S: 250-smtp.example.com
>>     S: 250 AUTH DIGEST-MD5 EXTERNAL
>>     C: AUTH EXTERNAL
>>     S: 235 Authentication successful.
>>
>>
>>8.    IANA Considerations
>>
>>8.1.  Guidelines for IANA
>>
>>  It is requested that IANA updates the SASL mechanisms registry as
>>  follows:
>>
>>     Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
>>     registrations to OBSOLETE.  Change the "Published specification"
>>     of the EXTERNAL mechanism to this document. Updated registration
>>     is provided in Section 8.6.
>>    
>>
>
>s/registration/registration information/
>
Done.

>>...
>>    
>>
>>10.    References
>>
>>10.1.  Normative References
>>
>>  [ABNF] Crocker, D. (Ed.), Overell, P., "Augmented BNF for Syntax
>>  Specifications: ABNF", RFC 2234, November 1997
>>
>>  [ASCII] American National Standards Institute, "Code Extension
>>  Techniques for Use with the 7-bit Coded Character Set of American
>>  National Standard Code (ASCII) for Information Interchange", FIPS PUB
>>  35, 1974
>>
>>  [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and
>>  Languages", RFC 2277, BCP 18, January 1998
>>
>>  [GSSAPI] Linn, J., "Generic Security Service Application Program
>>  Interface, Version 2, Update 1", RFC 2743, January 2000
>>
>>  [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) -
>>  Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993.
>>    
>>
>
>This reference is never used and hence should be deleted.
>
Done.

>>  [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
>>  Requirement Levels", RFC 2119, BCP 19, March 1997
>>
>>  [Unicode] The Unicode Consortium, "The Unicode Standard, Version
>>  3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading,
>>  MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the
>>  "Unicode Standard Annex #27: Unicode 3.1"
>>  (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard
>>  Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
>>
>>  [Stringprep] Hoffman, P., Blanchet, M., "Preparation of
>>  Internationalized Strings ("stringprep")", RFC 3454, December 2002.
>>
>>  [SASLprep] Zeilenga, K., "SASLprep: Stringprep profile for user names
>>  and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt.
>>
>>  [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
>>  RFC 3629, STD 63, November 2003.
>>
>>10.2.  Informative References
>>
>>  [SASL-GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", work in
>>  progress, draft-ietf-sasl-gssapi-XX.txt, November 2003
>>
>>  [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest
>>  Authentication as a SASL Mechanism", work in progress, draft-ietf-
>>  sasl-rfc2831bis-XX.txt, replaces RFC 2831
>>
>>  [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC
>>  2444, October 1998.
>>
>>  [SASL-SECURID] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC
>>  2808, April 2000.
>>
>>  [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
>>  2001.
>>
>>  [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication",
>>  RFC 2554, March 1999.
>>
>>  Being revised by Siemborski, R., "SMTP Service Extension for
>>  Authentication", work in progress, draft-siemborski-rfc2554bis-
>>  XX.txt.
>>    
>>
>
>This reference should be put into proper form.
>
I am not sure what exactly you suggest here.

>
>>  [XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol
>>  (XMPP): Core", work in progress, draft-ietf-xmpp-core-XX.txt.
>>
>>  [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
>>
>>
>>
>>A. Melnikov                                            FORMFEED[Page 21]
>>
>>
>>
>>
>>
>>Internet DRAFT                    SASL                  14 February 2004
>>
>>
>>  Encodings", RFC 3548, July 2003.
>>
>>  [RFC-INSTRUCTIONS] Postel, J., Reynolds, J., "Instructions to RFC
>>  Authors", RFC 2223, October 1997.
>>
>>  [IANA-SASL]  IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
>>  MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms.
>>
>>11.   Editor's Address
>>
>>    Alexey Melnikov
>>    Isode Limited
>>
>>    Email: [email-masked]
>>
>>12.   Acknowledgments
>>
>>  This document is a revision of RFC 2222 written by John G. Myers.  He
>>  also contributed significantly to this revision.
>>
>>  Magnus Nystrom provided the ASCII art used in Section 6.3.
>>
>>  Definition of partition was extracted from RFC 2617 ("HTTP
>>  Authentication: Basic and Digest Access Authentication").
>>
>>  Contributions of many members of the SASL mailing list are gratefully
>>  acknowledged, in particular Kurt D. Zeilenga, Peter Saint-Andre, Rob
>>  Siemborski, Jeffrey Hutzelman, Hallvard B Furuseth, Tony Hansen and
>>  Abhijit Menon-Sen for proofreading the document and various editorial
>>  suggestions.
>>    
>>
>
>Suggest you drop middle initials.
>
As you wish :-).

>Needs IPR notice.
Added.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 14 Mar 2004 08:57:30 +0000

Done.

>In the ABNF, I suggest (for consistency) replacing DIGIT, "-", and  
>"_" with %x30-39, %x2D, and %x5F, respectively.  This also avoids
>unnecessary reliance on a core rule (which would require the      
>implementor to look up meaning of DIGIT).
>
Done (it a slightly different manner).

>>  The following is an example of an EXTERNAL authentication in the SMTP
>>  protocol [SMTP].  In this example, the client is proxy
>>  authenticating, sending the authorization identity "fred" using in
>>  the (optional) initial response.  The server has determined the
>>  client's identity through IPsec and has a security policy that
>>  permits that identity to proxy authenticate as any other identity.
>>    
>>
>
>An informative reference for IPsec seems appropriate here as
>presently worded.  Suggest it be reworded,
>	The server has obtained the client's (authentication) identity
>	from an external service, such as IPsec, and has a security
>	policy that permits that identity to assume the identity of
>	the asserted authorization identity.
>
Done. I've also added an informative reference for IPSec, as it is 
mentioned in section 7.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 14 Mar 2004 08:37:55 +0000

Kurt D. Zeilenga wrote:

>At 01:39 PM 2/26/2004, Rob Siemborski wrote:
>  
>
>>Implementors of a protocol using this specification will also need
>>a specification of a profile specific the protocol. 
>>
>
>This is somewhat better.  My previous concern was with
>the "all of this document" part of the current statement.
>For the other audiences, the section is quite specific
>as to what portions of this document they need to read.
>I think we should detail what each audience should read
>with equal specificity.
>
>I have no objection to saying, in addition to portions
>of this document, they need to read the specification
>of the protocol they are implementing, especially those
>portions of that specification which fulfill the
>requirements placed upon that specification by this
>document.
>
>I note as well that it might be appropriate to note
>that implementors need to read and understand
>aspects of mechanism specifications they intend to
>use (regardless of whether they are implementing the
>mechanisms themselves or using an existing implementation)
>to understand, for instance, the mechanism specific
>authentication identity forms, the offered services,
>and security and other considerations.
>
I've rewrote the paragraph to look like this:

The sections "Overview", "Authentication Mechanisms",  "Protocol profile 
requirements", "Specific issues" and
"Security Considerations" cover issues that implementors of a protocol 
that uses SASL framework need to understand.
The implementors will also need to understand a specification of a 
profile specific to the protocol, as well as aspects of mechanism
specifications they intend to use (regardless of whether they are 
implementing the mechanisms themselves or using an existing implementation)
to understand, for instance, the mechanism specific authentication 
identity forms, the offered services, and security and other considerations.

(Note that I've borrowed the text that Kurt used in his message)

Comments?

Alexey

---

From: Rob Siemborski <[email-masked]>
Date: Mon, 1 Mar 2004 11:31:23 -0500 (EST)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 02 Mar 2004 07:59:20 +0900

I think it already does:

...

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 02 Mar 2004 09:15:56 +0900

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 02 Mar 2004 08:02:59 +0900

I like that.

Done.

Sounds good.

Ok
...

Done

Ok.

Done.

Done.

Thanks.

Changed.

Fixed.

Fixed.

I actually disagree.

Changed.

Done.

Done.

As you wish :-).

Added.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 14 Mar 2004 08:57:30 +0000

Done.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 14 Mar 2004 08:37:55 +0000

Comments?

Alexey