Subject: Implementers Guide Version 03d

From: "Cancio, Vivian" <[email-masked]>
Date: Fri, 8 Sep 2000 15:44:13 -0700

Please, review new version. October is our dateline. 
Section 5 was partly rewritten by D. Wing and also Section 6 was added to
clarify the encoding of '=' in ORCPT.

Vivian

---

From: Hiroshi Tamura <[email-masked]>
Date: Mon, 11 Sep 2000 09:10:20 +0900 (JST)

Vivian,

A comment as a chiar.
After collecting comments, please submit to [email-masked]
as version 03. Version 2 is formerly the latest I-D.

> clarify the encoding of '=' in ORCPT.

Editorial additions or modifications for Section 6 and References(section 9).

> 6. Implementation Issues for Internet Fax Addressing
> 
>  The GSTN addresses in e-mail addresses specifications (currently RFC2303, 
>  RFC2304 and RFC2846) require the use of the "=" and "+" characters inside
>  the local-part (see RFC822) and forward-path and reverse-path (see RFC821)
>  of the address. In these fields the "=" and "+" characters are allowed and
>  thus they MUST NOT be encoded in any way. Also other message headers fields
>  extensions (like Original-Recipient, see RFC2298) allows these characters
>  which thus MUST NOT be encoded.

RFC2303 -> RFC 2303 [A] or [A]
RFC2304 -> RFC 2304 [B] or [B]
RFC2846 -> RFC 2846 [C] or [C]

RFC822 -> RFC 822 [10] or [10]
RFC821 -> RFC 821 [11] or [11]
RFC2298 -> RFC 2298 [9] or [9]

>  However GSTN addresses can also appear in other fields, and in particular 
>  inside ESMTP parameters as esmtp-value (see RFC1869); the ORCPT parameter
>  (see RFC1891) is one of such cases. When the "=" and "+" characters in 
>  GSTN addresses appear as esmtp-value, they MUST be encoded as hexchar 
>  (see RFC1891).

RFC1869 -> RFC 1869 [D] or [D]
RFC1891 -> RFC 1891 [5] or [5]

Please add RFC references on [A],[B],[C],[D],[E] in section 7.
A:12
B:13
C:14
D:15
E:16

I do not read section 1 through 4 yet. But, if they are the same
as the version 02, no problems for me.

Regards,
--
Hiroshi Tamura, Ricoh Company, LTD.
E-mail: [email-masked]