Subject: Re: [EAI] proposal - can we reach consensus? - text for ascii@non-ascii issues

From: Shawn Steele <[email-masked]>
Date: Tue, 17 Aug 2010 23:25:19 +0000

John suggested:

> I've been trying to get the text we have been discussing clarified only because the Editor still believes, in good faith, that the WG wants these cases to be explicitly covered in some way.

> At another, I think it would be perfectly rational to include a statement in the introductory material to 5336bis (possibly with parallel language in 4952bis
(Framework) that said something like:

> "this specification applies only when a UTF8SMTPbis-aware client is trying to send a message that requires the UTF8SMTPbis extensions to a server that advertises the ability to handle those extensions as specified here.  For all other cases, and for addresses and messages that do not require the extension, SMTP clients and servers are expected to behave exactly as specified in RFC 5321 and its successors." and then drop all of this material.

Can we reach a consensus that something like the above in the introductory material would address people's concerns with UTF8SMTP and non-UTF8SMTP interoperability and then drop the text that is being hard to pin down?  Does anyone strongly object to this idea?  (I won't hold it against you?)

If someone does not think this is sufficient, I'd suggest adding John's suggested information anyway (to set expectations), and then attempting address only the specific points that someone thinks are important enough to add.  Hopefully we could then limit the discussion to a few specific thoughts rather than following the resulting chain to its natural conclusion and detailing each point.

Does that work?

-Shawn

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Aug 2010 19:38:49 -0400

--On Tuesday, August 17, 2010 23:25 +0000 Shawn Steele
<[email-masked]> wrote:

> John suggested:
> 
>> I've been trying to get the text we have been discussing
>> clarified only because the Editor still believes, in good
>> faith, that the WG wants these cases to be explicitly covered
>> in some way.
> 
>> At another, I think it would be perfectly rational to include
>> a statement in the introductory material to 5336bis (possibly
>> with parallel language in 4952bis
>> "this specification applies only when a UTF8SMTPbis-aware
>> client is trying to send a message that requires the
>> UTF8SMTPbis extensions to a server that advertises the
>> ability to handle those extensions as specified here.  For
>> all other cases, and for addresses and messages that do not
>> require the extension, SMTP clients and servers are expected
>> to behave exactly as specified in RFC 5321 and its
>> successors." and then drop all of this material.
> 
> Can we reach a consensus that something like the above in the
> introductory material would address people's concerns with
> UTF8SMTP and non-UTF8SMTP interoperability and then drop the
> text that is being hard to pin down?  Does anyone strongly
> object to this idea?  (I won't hold it against you?)
> 
> If someone does not think this is sufficient, I'd suggest
> adding John's suggested information anyway (to set
> expectations), and then attempting address only the specific
> points that someone thinks are important enough to add.
> Hopefully we could then limit the discussion to a few specific
> thoughts rather than following the resulting chain to its
> natural conclusion and detailing each point.
> 
> Does that work?

Speaking strictly as a participant in the WG, this seems like a
reasonable strategy.

    john

---

From: Shawn Steele <[email-masked]>
Date: Tue, 17 Aug 2010 23:42:02 +0000

In case it wasn't clear, it also works for me :)

-----Original Message-----
From: John C Klensin [mailto:[email-masked]] 
Sent: Tuesday, August 17, 2010 4:39 PM
To: Shawn Steele; Jiankang YAO; [email-masked]
Subject: RE: [EAI] proposal - can we reach consensus? - text for ascii@non-ascii issues

--On Tuesday, August 17, 2010 23:25 +0000 Shawn Steele <[email-masked]> wrote:

> John suggested:
> 
>> I've been trying to get the text we have been discussing clarified 
>> only because the Editor still believes, in good faith, that the WG 
>> wants these cases to be explicitly covered in some way.
> 
>> At another, I think it would be perfectly rational to include a 
>> statement in the introductory material to 5336bis (possibly with 
>> parallel language in 4952bis
>> "this specification applies only when a UTF8SMTPbis-aware client is 
>> trying to send a message that requires the UTF8SMTPbis extensions to 
>> a server that advertises the ability to handle those extensions as 
>> specified here.  For all other cases, and for addresses and messages 
>> that do not require the extension, SMTP clients and servers are 
>> expected to behave exactly as specified in RFC 5321 and its 
> introductory material would address people's concerns with UTF8SMTP 
> and non-UTF8SMTP interoperability and then drop the text that is being 
> hard to pin down?  Does anyone strongly object to this idea?  (I won't 
> hold it against you?)
> 
> If someone does not think this is sufficient, I'd suggest adding 
> John's suggested information anyway (to set expectations), and then 
> attempting address only the specific points that someone thinks are 
> important enough to add.
> thoughts rather than following the resulting chain to its natural 
> conclusion and detailing each point.
> 
> Does that work?

Speaking strictly as a participant in the WG, this seems like a reasonable strategy.

    john

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 18 Aug 2010 10:02:42 +0800

it works for me too.

Jiankang Yao

-----Original Message-----
From: John C Klensin [mailto:[email-masked]] 
Sent: Tuesday, August 17, 2010 4:39 PM
To: Shawn Steele; Jiankang YAO; [email-masked]
Subject: RE: [EAI] proposal - can we reach consensus? - text for ascii@non-ascii issues

    john

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 18 Aug 2010 09:59:44 -0400

> Can we reach a consensus that something like the above in the introductory material would address people's concerns with UTF8SMTP and non-UTF8SMTP interoperability and then drop the text that is be…

I prefer it to attempting to cover all the cases that someone might do
if they're not conforming to the RFCs we're working on.  To me,
attempting to list all the ways in which someone can do something
_other_ than the standard behaviour will just lead people to interpret
those descriptions as the right thing to do sometimes. 

A

-- 
Andrew Sullivan
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Aug 2010 08:56:26 -0600

On 8/18/10 7:59 AM, Andrew Sullivan wrote:
>>> "this specification applies only when a UTF8SMTPbis-aware client
>>> is trying to send a message that requires the UTF8SMTPbis
>>> extensions to a server that advertises the ability to handle
>>> those extensions as specified here.  For all other cases, and for
>>> addresses and messages that do not require the extension, SMTP
>>> clients and servers are expected to behave exactly as specified
>>> in RFC 5321 and its successors." and then drop all of this
>>> material.
>> 
>> and non-UTF8SMTP interoperability and then drop the text that is
>> being hard to pin down?  Does anyone strongly object to this idea?
>> (I won't hold it against you?)
> 
> I prefer it to attempting to cover all the cases that someone might
> do if they're not conforming to the RFCs we're working on.  To me, 
> _other_ than the standard behaviour will just lead people to
> interpret those descriptions as the right thing to do sometimes.

Agreed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/