Hi Brian,
On Fri, 11 Apr 2008, Brian Adamson wrote:
I appreciate your comments here. I plan to issue a new version of the draft
that addresses these to the extent I can. I have some questions about your
concerns with comments in-line below:
Thanks for your quick response. Below I won't
On Fri, Apr 11, 2008 at 11:04:24PM +0200,
Frank Ellermann [EMAIL PROTECTED] wrote
a message of 13 lines which said:
I don't find dir= in the HTML 4.01 spec.,
http://www.w3.org/TR/html401/struct/dirlang.html#h-8.2
8.2.2 Inheritance of text direction information
...
When the dir attribute
Stephane Bortzmeyer wrote:
I don't find dir= in the HTML 4.01 spec.,
http://www.w3.org/TR/html401/struct/dirlang.html#h-8.2
That permits LTR or RTL, bot not an empty dir=, or
is it another SGML oddity I've never before heard of ?
The dir= is probably here to reset the text direction
to
On Mon, Apr 14, 2008 at 10:24:35AM +0200,
Frank Ellermann [EMAIL PROTECTED] wrote
a message of 22 lines which said:
That permits LTR or RTL, bot not an empty dir=, or is it another
SGML oddity I've never before heard of ?
No, no, you're right, the important point I wanted you to read was
Stephane Bortzmeyer wrote:
as I said, otherwise, you could not express the fact that the
direction of the text in the bar element above is Not Known.
Without dir=, you could not cancel the directionality of
foo in its nested elements.
Well, yes, but so far the Web with all its (X)HTML pages
The following principles apply to spam control on IETF mailing lists:
* IETF mailing lists MUST provide spam control.
* Such spam control SHOULD track accepted practices used on the Internet.
* IETF mailing lists MUST provide a mechanism for legitimate technical
participants to bypass moderation,
I would suggest that the IESG also think about hosting all IETF lists in
house in the future.
The main reason for this is legal, a list that is maintained by the IETF
is much more satisfactory in a patent dispute than one run by a third
party. Last thing we want is to have patent trolls dragging
Pekka,
I appreciate your comments here. I plan to issue a new version of
the draft that addresses these to the extent I can. I have some
questions about your concerns with comments in-line below:
At 11:01 AM +0300 4/7/08, Pekka Savola wrote:
On Thu, 3 Apr 2008, The IESG wrote:
The IESG has
Speaking as president of the LPF; not a lawyer but a knowledgeable
layman.
I think you are correct that the patent issue is a red herring. The
patentee has the _right_ (not the obligation) to keep patent application
contents secret. Failure to keep the secret merely causes them to lose
the
On Mon, Apr 14, 2008 at 1:02 PM, Hallam-Baker, Phillip
[EMAIL PROTECTED] wrote:
I would suggest that the IESG also think about hosting all IETF lists in
house in the future.
The main reason for this is legal, a list that is maintained by the IETF
is much more satisfactory in a patent
Phill:
When IETF lists are housed somewhere other than ietf.org, they are
supposed to include an archive recipient so that there is an archive
available at ietf.org (perhaps in addition to the one kept at the
place where the list is housed).
Russ
At 01:02 PM 4/14/2008, Hallam-Baker,
Russ,
When IETF lists are housed somewhere other than ietf.org, they are
supposed to include an archive recipient so that there is an archive
available at ietf.org (perhaps in addition to the one kept at the
place where the list is housed).
I'll agree with Phill's conclusion on this
Eliot Lear wrote:
Russ,
When IETF lists are housed somewhere other than ietf.org, they are
supposed to include an archive recipient so that there is an archive
available at ietf.org (perhaps in addition to the one kept at the
place where the list is housed).
I'll agree
Russ Housley wrote:
When IETF lists are housed somewhere other than ietf.org,
they are supposed to include an archive recipient so that
there is an archive available at ietf.org
Makes sense. I have submitted some lists to other lists,
how is this archive recipient magic arranged ?
Frank
Hi,
On 2008-04-14 17:39 IESG Secretary said the following:
The following principles apply to spam control on IETF mailing lists:
* IETF mailing lists MUST provide spam control.
* Such spam control SHOULD track accepted practices used on the Internet.
* IETF mailing lists MUST provide a
The problem here is that what might appear to be a reasonable approach
and what can be proven to be a verifiable approach at reasonable cost
are not necessarily the same.
I would rather anticipate the problem rather than wait for an issue.
It is not just the message archives that are relevant,
Phill,
RFC 2026 requires that the Secretariat maintains records.
Whether they do so is of course an operational matter for
the IAOC, but from my personal knowledge they have always
been able to respond adequately to subpoenas. As you (and
RFC 2026) say, email archives are only a part of the
+1 to Henrik's comments. I don't think the two MUSTs
that he comments on are algorithmically possible.
Brian
On 2008-04-15 08:25, Henrik Levkowetz wrote:
Hi,
On 2008-04-14 17:39 IESG Secretary said the following:
The following principles apply to spam control on IETF mailing lists:
*
+1 to Henrik's comments. I don't think the two MUSTs
that he comments on are algorithmically possible.
These two MUSTs (the ability to whitelist specific posters without them having
to receive list mail and spam rejection) are both completely trivial to
implement with our software. The latter
On 2008-04-15 09:11, Ned Freed wrote:
+1 to Henrik's comments. I don't think the two MUSTs
that he comments on are algorithmically possible.
These two MUSTs (the ability to whitelist specific posters without them having
to receive list mail and spam rejection) are both completely trivial to
On 2008-04-14 23:11 Ned Freed said the following:
+1 to Henrik's comments. I don't think the two MUSTs
that he comments on are algorithmically possible.
These two MUSTs (the ability to whitelist specific posters without them having
to receive list mail and spam rejection) are both
Dear IESG,
IESG Secretary wrote:
The following principles apply to spam control on IETF mailing lists:
* IETF mailing lists MUST provide spam control.
* Such spam control SHOULD track accepted practices used on the Internet.
These two bullets are well-intentioned, but have no clear
On 2008-04-14 23:11 Ned Freed said the following:
+1 to Henrik's comments. I don't think the two MUSTs
that he comments on are algorithmically possible.
These two MUSTs (the ability to whitelist specific posters without them
having
to receive list mail and spam rejection) are both
On 2008-04-15 00:35 Ned Freed said the following:
On 2008-04-14 23:11 Ned Freed said the following:
I guess I should be flattered, but really, I fail to see why. Guaranteed
bypass
of moderation is simply an allowed-poster whitelist.
So it seems to me that you've failed to see the problem.
shepherd hat on
During the second last call for rfc2821bis, there has been much
discussion of how the implicit MX handling is to be handled in an
IPv6-capable and IPv6-only environment.
This has generated much heat, as well as numerous proposals that were
both productive and counter-productive,
On 2008-04-15 00:35 Ned Freed said the following:
On 2008-04-14 23:11 Ned Freed said the following:
I guess I should be flattered, but really, I fail to see why. Guaranteed
bypass
of moderation is simply an allowed-poster whitelist.
So it seems to me that you've failed to see the
Hi -
From: Ned Freed [EMAIL PROTECTED]
To: Henrik Levkowetz [EMAIL PROTECTED]
Cc: Ned Freed [EMAIL PROTECTED]; ietf@ietf.org
Sent: Monday, April 14, 2008 9:12 PM
Subject: Re: IESG Statement on Spam Control on IETF Mailing Lists
...
And there's that word automatically. There is nothing in
Tony Hansen wrote:
From this viewpoint, running code wins.
I'm also swayed by the principle of least surprise.
...
Last of all, I'm swayed by the discussions around RFC 974 and the DRUMS
archive search
...
So the bottom line is that I see sufficient support for including
lookups
The following principles apply to spam control on IETF mailing lists:
* IETF mailing lists MUST provide spam control.
* Such spam control SHOULD track accepted practices used on the Internet.
These two bullets are well-intentioned, but have no clear meaning. Simply
put,
there is no
Dave Crocker wrote:
Tony Hansen wrote:
From this viewpoint, running code wins.
I'm also swayed by the principle of least surprise.
...
Last of all, I'm swayed by the discussions around RFC 974 and the DRUMS
archive search
...
So the bottom line is that I see sufficient support for
* IETF mailing lists MUST provide a mechanism for legitimate technical
participants to bypass moderation, challenge-response, or other techniques
that would interfere with a prompt technical debate on the mailing list
without requiring such participants to receive list traffic.
Here,
Hi -
From: Ned Freed [EMAIL PROTECTED]
To: Henrik Levkowetz [EMAIL PROTECTED]
Cc: Ned Freed [EMAIL PROTECTED]; ietf@ietf.org
Sent: Monday, April 14, 2008 9:12 PM
Subject: Re: IESG Statement on Spam Control on IETF Mailing Lists
...
And there's that word automatically. There is
The IESG has approved the following document:
- 'IPv6 Deployment Scenarios in 802.16 Networks '
draft-ietf-v6ops-802-16-deployment-scenarios-07.txt as an Informational RFC
This document is the product of the IPv6 Operations Working Group.
The IESG contact persons are Ron Bonica and Dan
The IESG has approved the following document:
- 'Mobile IPv6 Fast Handovers for 3G CDMA Networks '
draft-ietf-mipshop-3gfh-07.txt as an Informational RFC
This document is the product of the Mobility for IP: Performance,
Signaling and Handoff Optimization Working Group.
The IESG contact
The following principles apply to spam control on IETF mailing lists:
* IETF mailing lists MUST provide spam control.
* Such spam control SHOULD track accepted practices used on the Internet.
* IETF mailing lists MUST provide a mechanism for legitimate technical
participants to bypass moderation,
The An Open Specification for Pretty Good Privacy working group (openpgp)
in the Security Area has concluded.
The IESG contact persons are Tim Polk and Pasi Eronen.
The mailing list will remain active.
The openpgp working group has successfully completed its objective of
publishing a message
The IESG has approved the following document:
- 'Mobile IPv4 Traversal Across IPsec-based VPN Gateways '
draft-ietf-mip4-vpn-problem-solution-05.txt as a Proposed Standard
This document is the product of the Mobility for IPv4 Working Group.
The IESG contact persons are Jari Arkko and Mark
37 matches
Mail list logo
