On Mar 20, 2008, at 3:30 PM, John C Klensin wrote:
--On Friday, 21 March, 2008 09:03 +1100 Mark Andrews
[EMAIL PROTECTED] wrote:
I think Doug is saying don't let domains with just
records be treated as valid RHS of email. Today we
have to add records to domains with
Does the IETF have a policy regarding misrepresented identities?
In the particular incident, it is assumed that the person using the name of a
famous French aviation pioneer is in fact someone else. On the one hand, using
pseudonyms is a form of free speech. But on the other hand, in a standard
Soencer,
thanks for your review!
Some comments... I'm not addressing editorials...
Spencer Dawkins skrev:
This document specifies an experimental variant of Internet mail that
permits the use of Unicode encoded in UTF-8 [RFC3629], rather than
ASCII, as the base form for Internet email
Hi, Harald,
Thanks for the quick feedback (Gen-ART reviewers like this because we can
remember writing the review, and at least part of what we were thinking
about :-)
Looks like mostly goodness. If we're in synch, I dropped it from this
e-mail.
Spencer
1.2. Relation to other standards
One addition to Harald's comments...
--On Sunday, 23 March, 2008 20:43 +0100 Harald Tveit Alvestrand
[EMAIL PROTECTED] wrote:
Because internationalized local parts may cause email
addresses to be longer, processes which parse, store, or
handle email addresses or local parts must take
On Sun, Mar 23, 2008 at 08:45:19AM -0700, Christian Huitema wrote:
Does the IETF have a policy regarding misrepresented identities?
In the particular incident, it is assumed that the person using the
name of a famous French aviation pioneer is in fact someone else. On
the one hand, using
Doug,
--On Saturday, 22 March, 2008 23:02 -0700 Douglas Otis
[EMAIL PROTECTED] wrote:
...
In the past you had made several comments that RFC2821bis
would not change SMTP, and that you had also stated
records where NOT defined as SMTP server discovery records.
(Not in those words of
Vidya,
... do the responsible thing, which would be to clearly define the
applicability, along with providing an interoperable means of defining
the key hierarchy for those usages that want to/can use it.
This is all I'm suggesting we do. I think we should add text to the
document that
For example, consider using a USRK to secure HTTP. If your access
provider did this to deliver firmware updates to your handset, this
might be reasonable, but if amazon.com required it for authentication,
this would be unreasonable.
I do not believe that either application is reasonable.
