Re: regarding draft-myers-smtp-auth-08.txt

["Jack De Winter" <[e-mail]>]

At 12:30 PM 1/8/98 -0800, Chris Newman wrote:
>On Thu, 8 Jan 1998, Jack De Winter wrote:
>> how would we encode that so that it could be passed as an authentication
>> token, seeing as it is perfectly valid according to the RFC822
>> construction rules for addr-spec?
>
>Good question.  I believe the SMTP AUTH spec should be revised to use the
>encoding described in section 5 of RFC 1891.

To be more specific:

5.  Additional parameters for RCPT and MAIL commands

   The extended RCPT and MAIL commands are issued by a client when it
   wishes to request a DSN from the server, under certain conditions,
   for a particular recipient.  The extended RCPT and MAIL commands are
   identical to the RCPT and MAIL commands defined in [1], except that
   one or more of the following parameters appear after the sender or
   recipient address, respectively.  The general syntax for extended
   SMTP commands is defined in [4].

   NOTE: Although RFC 822 ABNF is used to describe the syntax of these
   parameters, they are not, in the language of that document,
   "structured field bodies".  Therefore, while parentheses MAY appear
   within an emstp-value, they are not recognized as comment delimiters.

   The syntax for "esmtp-value" in [4] does not allow SP, "=", control
   characters, or characters outside the traditional ASCII range of 1-
   127 decimal to be transmitted in an esmtp-value.  Because the ENVID
   and ORCPT parameters may need to convey values outside this range,
   the esmtp-values for these parameters are encoded as "xtext".
   "xtext" is formally defined as follows:

     xtext = *( xchar / hexchar )

     xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
          except for "+" and "=".

; "hexchar"s are intended to encode octets that cannot appear
; as ASCII characters within an esmtp-value.

     hexchar = ASCII "+" immediately followed by two upper case
          hexadecimal digits

When encoding an octet sequence as xtext:

+ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=",
  MAY be encoded as itself.  (A CHAR in this range MAY instead be
  encoded as a "hexchar", at the implementor's discretion.)

+ ASCII CHARs that fall outside the range above must be encoded as
  "hexchar".

Is there any reason why we should use this approach instead of the
Quoted-Printable approach?  I know its a difference of whether or
not the character is a % or a +, but just curious.

Also, the 129 character limit, is that 129 characters after or before
any translation to hexchars are applied?

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
[phone]		http://www.wildbear.on.ca/jacks/