Subject: [EAI] EDITORIAL: dsn-03 1..3 (at the end it's an ISSUE: dsn HEXPOINT)

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 24 Sep 2007 21:24:56 +0200

2:
-| and the rules in section 4 of RFC 3629.

Lack of caffeine, I really clicked on the rfcmarkup
link to check what you're talking about.  Maybe say:

+| and the UTF-8 syntax rules in section 4 of RFC 3629.

3:
| I.e. the utf-8-address form MUST NOT be used in the
| ORCPT parameter when the SMTP server doesn't advertise
| support for UTF8SMTP or the SMTP server supports
| UTF8SMTP, but the address contains US-ASCII characters
| not permitted in the ORCPT parameter (e.g. the ORCPT
| parameter forbids unencoded SP and =); or in a 
| 7-bit transport environment including a 
| message/delivery-status Original-Recipient or
| Final-Recipient field.

Hard to parse.  How about an ordered list [...] "when:"
"1: the SMTP server doesn't advertise UTF8SMTP" [...],
"2: the SMTP server supports UTF8SMTP, but" [...],
"3: in a 7-bit transport environment" [...].

| In the former case the utf-8-addr-xtext form
What's the former case here, the "1" in my proposal ?
| in the latter case the utf-8-addr-unitext form
If the latter case is "3", what about "2" ?

The prose is really hardcore, I had to jump forward
to the ABNF to get a vague idea what you're talking
about.

An <utf-8-address> is apparently a "raw" <uMailbox>
with an optional ASCII <Mailbox> in angle brackets
for the optional Alt-Address.  Readers need to know
this before you start with the MUSTard and the fine
print.

Then there's a problem with some ASCII characters
not allowed in ORCPT.  For that you introduce an 
<utf-8-addr-xtext> term, which is the 3461-xtext
encoding of a <utf-8-addr-unitext>.   

And <utf-8-addr-unitext> is apparently any UTF-8
character excluding CTLs, SP, "\", "+", and "=",
where you need an \x... notation with the name
<EmbeddedUnicodeChar>.

[The remark "printable" for QUCHAR confuses me,
 not all non-ASCII UTF-8 characters are printable].

Another question, if an <utf-8-address> contains
an Alt-Address, then it also contains 1*WSP as a
separator between uMailbox and "<" Mailbox ">".
Often WSP is SP, and that's not allowed for the
ORCPT magic, is that correct ?  How about some
examples ?

The HEXPOINT syntax is completely beyond me, what
is this about ?  What problem are you trying to
solve ?  Why can't you use simple hex. NCRs, and
be done with it ?  

 Frank

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 27 Sep 2007 12:05:59 +0100

>+| and the UTF-8 syntax rules in section 4 of RFC 3629.
Ok.

>"3: in a 7-bit transport environment" [...].
I've done something like that.

>What's the former case here, the "1" in my proposal ?
Yes.

>If the latter case is "3", what about "2" ?
utf-8-addr-unitext should be used in both cases 2 and 3. I will clarify.

>to the ABNF to get a vague idea what you're talking
It was very painful to come up with a way of describing 3 layer syntax.

>this before you start with the MUSTard and the fine
Any specific suggestions?

>where you need an \x... notation with the name
Correct.

> not all non-ASCII UTF-8 characters are printable].
Printable was regarding US-ASCII subset. I've changed to clarify.

>ORCPT magic, is that correct ?
>
Correct.

>How about some examples ?
>
I will think about that.

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 27 Sep 2007 20:46:49 +0200

> I've done something like that.

Thanks.

> It was very painful to come up with a way of describing

Yes, and hard to groke because I've forgotten the details
since I read an earlier version months ago.

> Any specific suggestions?

Maybe introduce <utf-8-address> (prose and ABNF) first,
separate subsection.  

Then explain the issue with ORCPT in DSNs, quoting 3461.
Admittedly "xtext" and its motivation isn't something I
know by heart.  That could be a second subsection.

After that explain your solution and its ABNF, with a
hint that the HEXPOINT is in fact simple, only the ABNF
is horrible because it tries to eliminate surrogates.

> Correct.

Okay.  But don't propose to use HT instead of SP... ;-)

>> How about some examples ?

Maybe you can use the example in the Jabber-ID draft:
ji&#x159;i@&#x10D;echy.example (ASCII with hex. NCRs)
ji%C5%99i@%C4%8Dechy.example (percent encoded UTF-8)

For a convincing alt-address <[email-masked]>
you'd need the xn--form of &#x10D;echy.  You could
then use this example with and without alt-address
to explore the wonders of "xtext" and SP.

 Frank