On Sat, 2006-07-22 at 06:51 -0700, todd glassey wrote:
The question as to why that initiative's process was stalled would
have to be answered to be fair. One would have to take into
consideration whether the underlying technologies were the issue,
those undertaking the effort abandoned it, or
On Jul 21, 2006, at 8:27 AM, Dave Crocker wrote:
David Harrington wrote:
Why not start everything at Experimental, and if it gains market
success then it moves to Full.
why not make the smallest change we can, rather than alter the
existing, basic mechanism for entering standards track
On Jul 13, 2006, at 3:25 PM, Eliot Lear wrote:
We are in this position because we are not today documenting
existing practice, having not properly understood the lack of
desire to do what you class as minor amount of work.
The SRD approach generates Name.Serial references to sets of
On Sun, 2006-06-18 at 22:05 -0700, C. M. Heard wrote:
[ follow-ups to IETF discussion list please]
Of the three possible ways forward suggested by this draft, I think that
the only one that's likely to get done is this one:
1. Agree that, apart from day to day efforts to improve
On Sun, 2006-06-11 at 09:04 -0400, Keith Moore wrote:
The general circumstances under which IETF has trouble designing new
protocols are either or both of these: 1. When there are substantial
conflicts between major industry players about strategic direction in
that area. 2. When the
On Sat, 2006-06-10 at 09:17 +0200, Brian E Carpenter wrote:
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-newtrk-questions-00.txt
,---
|The three possible ways forward are:
|
| 1. Agree that, apart from day to day efforts to improve efficiency,
|
,
|1.2. Document Structure
|...
|
| The sections dealing with attacks on DKIM each begin with a table
| summarizing the postulated attacks in each category along with their
| expected impact and likelihood. The following definitions were used
| as rough criteria for scoring the attacks:
|
|
On Jan 25, 2006, at 2:08 PM, Harald Tveit Alvestrand wrote:
We had a discussion on this back in May 2003, and I created a
mailing list for it called ietf-moderation - you can subscribe to
the list by http://eikenes.alvestrand.no/mailman/listinfo/ietf-
moderation, or the usual -request
On Jan 13, 2006, at 12:07 PM, Dave Crocker wrote:
What is important is not the files used to tailor the production
service, but the prevalence of expertise and tools for that service.
In reality, nroff expertise is isolated in a tiny community. In
reality, xml expertise has become
On Jan 10, 2006, at 5:47 PM, Dave Crocker wrote:
Lucy, I suspect that they merely were making a spelling error,
since I'm sure they were referring to folk who are truly essential,
and therefore qualify as linch pins...
I have never heard of a linching party. RFCs filled with base64
On Jan 11, 2006, at 1:52 PM, John C Klensin wrote:
--On Wednesday, 11 January, 2006 13:02 -0800 Bob Braden
[EMAIL PROTECTED] wrote:
Your knowledge is apparently incomplete. The RFC Editor has been
actively experimenting with using xml2rfc for publication, and we
have been passing our
On Jan 5, 2006, at 11:31 AM, John Levine wrote:
Quite frankly, I believe we can address the second step (which of
the requirements are not met today?) with a firm none.
One is that ASCII doesn't permit adequately beautiful pictures. If
that's the problem to be solved, it seems to me that
On Jan 4, 2006, at 9:59 AM, Dave Crocker wrote:
E AS I understand it the concern is that people who don't use DKIM
will eventually not be able to send e-mail to people who are using
it. I'm not sure that this is something that people should be
concerned about, indeed, the logic of this
On Mon, 2006-01-02 at 10:58 -0500, Tony Hansen wrote:
This thread was begun by the last call on the chartering of DKIM.
Can we please get back to the question of chartering DKIM?
The concern raised was not specifically in regard to the base DKIM
draft. There was concern with respect to the
On Mon, 2006-01-02 at 06:41 +0100, Frank Ellermann wrote:
Douglas Otis wrote:
AFAIK it's a way to check if mail claiming to be from [EMAIL PROTECTED]
was originally sent from [EMAIL PROTECTED] - if that's correct nothing is
wrong with the idea so far, domain y only needs a name server
On Mon, 2006-01-02 at 22:27 +, John Levine wrote:
PDF is a fine display format, but it is a rather poor editing format
since it's hard to do any more with PDF (even PDF/A) than either to
print it or to extract the text from it. XML on the other hand is a
putrid display format but it is
On Jan 1, 2006, at 8:35 AM, John C Klensin wrote:
--On Sunday, 01 January, 2006 04:35 + John Levine
[EMAIL PROTECTED] wrote:
I hope the message here is not that we should restrict ourselves
to developing technology that is idiot-proof, since a sufficiently
determined idiot, of which
On Dec 31, 2005, at 10:31 PM, Frank Ellermann wrote:
Douglas Otis wrote:
The BATV draft seems to be a good start. Perhaps it can be
further simplified. Could this satisfy both camps?
Which both camps, SES vs. BATV, STD 10 + SPF vs. STD 3 + 2821, or
something else ? For the former I'm
On Fri, 2005-12-30 at 09:35 +0100, Frank Ellermann wrote:
Douglas Otis wrote:
This back-scatter problem can be resolved by implementing
BATV at the cost of two additional wafer-thin packets.
Simplified SES (or whatever BATV is) is _more_ restrictive
than SPF:
With effort, a compatible
On Dec 27, 2005, at 5:20 PM, Frank Ellermann wrote:
Douglas Otis wrote:
The response was specifically against the use of authorization.
With respect to SPF/Sender-ID or SSP, these are indeed email-
address authorization schemes.
There's no burden shifting. If you have a PASS you know
On Dec 27, 2005, at 7:33 AM, Nathaniel Borenstein wrote:
I'm sorry, the authorization method was an echo of the term used
in the mail I was replying to (which is why it was in quotes). I
was really trying to generalize to a whole range of technologies
without making my wording too
On Fri, 2005-12-23 at 17:27 -0500, Nathaniel Borenstein wrote:
Far from trying to leave only one authorization method, the DKIM
effort is an attempt to show, by example, how an arbitrary number of
such methods might eventually be elaborated and standardized.
There is danger viewing any
On Dec 22, 2005, at 8:38 AM, Keith Moore wrote:
If your goal is gaining consensus on a useful specification in the
shortest amount of time, it makes far more sense to work on the
different aspects of the problem in parallel rather than serially.
My concern regarding the charter is related
On Dec 22, 2005, at 12:06 PM, Frank Ellermann wrote:
Douglas Otis wrote:
DKIM should be seen as aspect of the SMTP transport.
It could also work for news if we get the FWS canonicalization right.
Agreed. The presents of the signature should not impose limitation
upon what content
On Dec 19, 2005, at 2:28 PM, Frank Ellermann wrote:
Disrupting v=spf1 at this point also spells doom for SMTP. What
we'll now get is SMPT-3, a new SMTP without most NDNs. Only a few
pockets of resistance with an SPF sender policy will still say that
NDNs are good IFF you reject SPF
On Wed, 2005-12-14 at 07:06 -0800, william(at)elan.net wrote:
On Tue, 13 Dec 2005, Douglas Otis wrote:
You can do setup that involves multiple CNAME and NS redirections
with DNS and it all could come to those 100 lookups.
Few would expect this to work, nor would that be a _required_ depth
On Dec 14, 2005, at 9:42 AM, william(at)elan.net wrote:
And as far as my opinion using BATV/SES together with SPF makes more
sense - both in reducing computation cryptographic computation when
it does not have to be used and also because by itself BATV/SES are
easily susceptible to a replay
On Dec 14, 2005, at 9:38 AM, Frank Ellermann wrote:
Anybody experimenting with combinations will be delighted to
learn that (s)he's now expected to opt out from PRA first.
The opt-out of PRA is actually opt-in using the spf2.0/pra ?all
record.
This PRA record would likely still fall
On Mon, 2005-12-12 at 13:51 -0600, wayne wrote:
Well, I can see coming back some day and trying to create an update to
the SPF protocol. I can't see trying to change SPF version 1.
The problem with SPF draft is there is no spf2.0/mfrom. This has little
to do the IETF, but rather a
On Dec 13, 2005, at 11:07 AM, wayne wrote:
However, his complaints could not have possibly had any impact on
the current limits in the SPF spec.
The reduction to 111 DNS lookups is not a resounding impact with
respect to this concern. Defending this sequential lookup
requirement will
On Dec 6, 2005, at 2:27 PM, Frank Ellermann wrote:
Douglas Otis wrote:
this could also mean utilizing graphical characters to create
clean lines, boxes, and borders. This could be a matter of the
character-repertoire going beyond ASCII in conjunction with a
drawing application
On Sun, 2005-12-04 at 12:22 +0100, Henrik Levkowetz wrote:
on 2005-12-04 08:52 Doug Ewell said the following:
Perhaps it's just me, but I find it bizarre that the question of
limiting RFC text to ASCII vs. UTF-8 is being conflated with the
question of limiting RFC illustrations to ASCII
On Sun, 2005-12-04 at 16:29 -0500, Sam Hartman wrote:
Daniel == Daniel Feenberg [EMAIL PROTECTED] writes:
Daniel Is there a proper place to discuss
Daniel
http://www.ietf.org/internet-drafts/draft-church-dnsbl-harmful-o1.txt
Daniel ?
You can talk to the author of that
On Wed, 2005-11-30 at 18:29 -0800, Paul Hoffman wrote:
No escape mechanism is needed. Non-displayable characters are still
in the RFC, they simply can't be displayed by everyone (but they can
be displayed by many). This is infinitely simpler, and a much better
long-term solution, than an
On Dec 1, 2005, at 8:34 AM, Paul Hoffman wrote:
The suggestion of the HTML escape would ensure readability.
Fully disagree. Listing an author as Patrik Fauml;ltstrouml;m is
not readable.
The suggestion was for an alternate field in the XML input file to
contain non-ASCII versions of
On Dec 1, 2005, at 11:31 AM, Hallam-Baker, Phillip wrote:
A much better way to solve this problem is to introduce a pointer RR
that obeys the semantics of *.example.com or #.example.com the same as
any other non-prefixed pointer. The resolution process for a prefixed
record then becomes :
1)
On Nov 29, 2005, at 1:53 PM, Gray, Eric wrote:
One issue with to quickly responding to Bob's earlier
questions is that the XML version - as Christian has already
said - cannot be the authoritative/normative version of an
RFC. I would qualify that someone by allowing that an XML
On Nov 30, 2005, at 12:41 PM, Frank Ellermann wrote:
Robert Sayre wrote:
I'm sure someone has already suggested this approach,
but I'll add my voice to the chorus.
http://tools.ietf.org/html/draft-hoffman-utf8-rfcs
I really don't like this approach for various reasons.
Rather than
On Nov 30, 2005, at 2:23 PM, Paul Hoffman wrote:
At 1:54 PM -0800 11/30/05, Douglas Otis wrote:
Rather than opening RFCs to text utilizing any character-set
anywhere, as this draft suggests,
That is not what the RFC suggests at all. The character set is
Unicode. The encoding is UTF-8
On Wed, 2005-11-23 at 20:31 -0500, John C Klensin wrote:
Folks, not to be a stick-in-the-mud, but one of the things that
has made the RFC Editor process attractive for authors is that
it is possible to design and use the right format for a
particular presentation. Sometimes that means
On Nov 21, 2005, at 12:54 AM, [EMAIL PROTECTED] wrote:
The IETF is probably the ONLY meaningful organisation in the world
that insists on using ascii-only specifications. Any
rationalization of that practise should try to explain why we are
so exceptional before embarking on specious
On Aug 26, 2005, at 7:53 AM, wayne wrote:
In [EMAIL PROTECTED] Andrew Newton
[EMAIL PROTECTED] writes:
But since you brought this up: if you (the author of the document) do
not consider this to be an experiment, then perhaps the IETF should
not publish SPF as an Experimental RFC.
I
On Aug 26, 2005, at 12:56 PM, wayne wrote:
In [EMAIL PROTECTED] Douglas
Otis [EMAIL PROTECTED] writes:
If the goal of the SPF Classic draft was intended to capture a point
in time pre-dating semantic extensions related to RFC-2822 defined
content, then perhaps the draft should
On Sat, 2005-08-27 at 12:00 -0700, william(at)elan.net wrote:
But if reuse of spf1 records is really realy the only way for MS
and it wants to continue, then the only possibility for negotiation
I see is to get it part the way for both sides. This would involve:
1. MS agrees to change its
On Aug 25, 2005, at 11:26 AM, Ned Freed wrote:
A mail-sending domain indicates that it is participating by
publishing
certain DNS RR's.
Crucially, a mail-sending domain cannot opt in to the SPF experiment
without also opting in to the senderid experiment. This renders any
claimed results
201 - 245 of 245 matches
Mail list logo
