SM wrote:
What about senders from small emerging market countries having a very
hard time getting any widely accepted assurance group to vouch for them?
Also in more mature markets, not all of the existing companies and
universities running their own mail servers will be eager to spend
John Levine wrote:
If some group wanted to build a closed pay-to-play mail system, they
could do it with the tools they already have, using SMTP AUTH or
STARTTLS with a private signing cert or VPNs or whatever. The reason
they don't is that it makes no sense, and a tiny tweak like VBR isn't
John R. Levine wrote:
The other thing I don't understand is why you minimize the expected
VBR effect. (If that's meant as an apotropaic stance, I have no
objection. Otherwise,) I wonder why we shouldn't push VBR as hard as
we can, if it can stop spam.
Could you point out where anyone,
J.D. Falk wrote:
Dave CROCKER wrote: [...]
Reading through the archives, it quickly becomes clear that the
arguments against accepting draft-hoffman-dac-vbr are actually arguments
against potential bad decisions on the part of mail system operators.
They're arguments against a big ISP like
Doug Ewell wrote:
I thought Stallman was considered a major religious figure.
Only when he wears that hat
http://uncyclopedia.wikia.com/wiki/St._Ignucius
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hallam-Baker, Phillip wrote:
I think Melinda makes a good point here.
[..]
RMS has a certain number of supporters who are willing to write letters.
That does not mean that RMS's opinion should hold greater weight than
that of other people.
We must assume that each writer is expressing
John Levine wrote:
Despite currently excessive number of comments, I think we should invite
more comments and make it easier, not harder to send them. Even if
traffic on the list is now too high and information content per message
is low, in general our average number of comments in the IETF
Doug Otis wrote:
Since *authorization* does not *authenticate* a domain as having
originated a message, this leaves just the IP address of the SMTP client
as a weakly authenticated origin identifier. The IP address of the
SMTP client is the input for Sender-ID or SPF *authorization*
Hi,
Douglas Otis wrote:
There are hundreds of thousands of legitimate SMTP clients in comparison
to hundreds of millions of domains.
My understanding is that recipients are only interested in a few
domain names: their company, their banks, their customers, their
providers, and the like.
Douglas Otis wrote:
ESPs optimize profits by reducing their
support calls. To do this, they might reduce erroneous rejections by
tweaking SPF to make guesses. As such, it is not safe to assume that
because the ESP accepted a message from an authorized SMTP client, that:
A) the SMTP
Marc Petit-Huguenin wrote:
I would like to bring to your attention this proposal to put back
running code at the center of Internet protocol design by adding a
new Considerations Section in future Internet-Drafts and RFCs:
SM wrote:
A request for publication as
Experimental may get rejected if the publication is deemed harmful.
Does that include legal threats?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Apparently, publishing a message as experimental is an invitation by
the IETF to experiment with a new protocol. What sense does that bear,
if accepting IETF invitations is likely to result in legal troubles?
grenville armitage wrote:
Lawrence Rosen wrote:
[..]
Or are some at IETF
John Levine wrote:
Apparently, publishing a message as experimental is an invitation
by the IETF to experiment with a new protocol. What sense does that
bear, if accepting IETF invitations is likely to result in legal
troubles?
In North America, at least, experimentation per se doesn't
Douglas Otis wrote:
Just using TCP would prevent most of the DNS poisoning attacks that
Amir's paper reports.
TCP is prone to DDoS attack. As such, TCP is seldom used with DNS.
I thought TCP was the default when the UDP message size is not enough.
That's, AFAIK, the only advantage of TCP
Stephane Bortzmeyer wrote:
It seems that DNS over SCTP would solve 90% of the problems with 10%
of the efforts and resources required to implement DNSSEC. However,
I hear more often about the latter than the former. How come?
I've read this message via the IETF general mailing list and so I
Stephane Bortzmeyer wrote:
On Thu, May 28, 2009 at 04:16:31PM +0200,
Alessandro Vesely ves...@tana.it wrote
a message of 14 lines which said:
The discussion was about how to get rid of the threats illustrated,
e.g., in Kaminsky, D.: It?s the end of the cache as we know it.
I know about
Paul Wouters wrote:
On Thu, 28 May 2009, Alessandro Vesely wrote:
The limitations in TCP or SCTP security stem from
transport security is pretty meaningless in the DNS world which operates
using a distributed caching system.
One has to trust each cache! Given that it is pretty easy
David Conrad wrote:
However, pragmatically speaking, I suspect it is going to be much, much
easier to get DNSSEC deployed than it would be to get every
router/firewall/NAT manufacturer and network operator to support/deploy
SCTP, not to mention getting every DNSSEC server to support DNS over
Dean Anderson wrote:
TCP is used by many, if not all, resolvers to get large responses.
And I'm working on changes to DJBDNS dnscache that enable a
configuration option to use TCP by default and fall back to UDP if TCP
is not available.
As that would increase security, I imagine that many
David Conrad wrote:
Given that it is pretty easy to predict a subset of the queries a
given server will issue in a give time frame, using SCTP can improve
reliability better than adding another 32bit random number.
1) It isn't easy
What did your mail server look up after receiving this
Paul Wouters wrote:
On Fri, 29 May 2009, Alessandro Vesely wrote:
It's what the patch has reinforced. SCTP is more secure than the
patched bind, yet easier than DNSSEC.
where easier means update all the root and TLD servers and load balancers
and what not to support DNS over SCTP. While
Wouldn't the tool add the complete URL, please?
Fearghas McKay wrote:
On 16 Jun 2009, at 12:28, Alessandro Vesely wrote:
Someone suggested I should also have posted an URL. Those are just
practical issues.
Yes a practical issue if you want people to comment on your Draft - make
it easy
the inefficiencies that TCP would
introduce.
On Thu, May 28, 2009 at 10:16 AM, Alessandro Vesely ves...@tana.it
mailto:ves...@tana.it wrote:
Stephane Bortzmeyer wrote:
It seems that DNS over SCTP would solve 90% of the problems with 10%
of the efforts and resources required
On http://www.ietf.org/glossary.html there are very few terms.
Is there a way to add most used acronyms?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
On 22/Jan/10 17:47, Scott Brim wrote:
Dean Willis allegedly wrote on 01/22/2010 02:56 EST:
As somebody who makes a living explaining patents to people who feel
threatened by an infringement suit, the simple fact is that the IETF is
appallingly (and blissfully) ignorant of the vast number of
On 19/Mar/10 14:59, MtFBwU wrote:
The Internet censorship in China makes many people suffer a lot, it also makes
me think a lot, both politically and technically. But I believe in technology,
especially the Internet.
I hope IETF's meeting in Beijing will be one more occasion to restate
that
On 24/Mar/10 00:18, todd glassey wrote:
On 3/23/2010 2:39 PM, Dean Willis wrote:
Obligatoy protest: And given the Google debacle, why are we still going
to Beijing?
Because the IETF is about creating Intellectual Properties regarding
networksing. Not a Political Action Committee...
That's
On 24/Mar/10 09:38, Spencer Dawkins wrote:
Because the IETF is about creating Intellectual Properties regarding
networksing. Not a Political Action Committee...
That's the worst definition of the IETF I've ever heard! I don't
believe that, and don't think ISOC believes that either.
I would
On 24/Mar/10 18:50, todd glassey wrote:
The Internet isn't value-neutral, and neither is the IETF.
AMEN!
We want
the Internet to be useful for communities that share our commitment
to openness and fairness.
But the IETF is not open to opinions which vary from its core stated
On 03/May/10 22:26, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Authentication-Results Registration For Differentiating Among
Cryptographic Results '
draft-kucherawy-authres-header-b-01.txt as a Proposed Standard
On 20/Jun/10 11:53, SM wrote:
The reader will note that neither implementation nor operational
experience is required. In practice, the IESG does require
implementation and/or operational experience prior to granting Proposed
Standard status. Implementors do not treat Proposed Standards as
Hi SM,
the examples you give are /very/ significant, because of the miserable
state of affairs that currently characterizes email.
On 27/Jun/10 19:32, SM wrote:
If you then go to RFC 2821 and you will see that it is a Proposed
Standard which has been obsoleted by RFC 5321 (Draft Standard).
On 30/Jun/10 17:52, Jari Arkko wrote:
John [Klensin],
and I'm keenly aware of the fact that
errata, even approved errata, do not constitute community
consensus documents, but,
I am with you on that.
IMHO, this is a point that may be worth enhancing. From a functional
POV, it is not
On 16/Sep/10 01:57, John C Klensin wrote:
[...] I think it is safe to conclude that the rough consensus in
the email is that the mechanism is really not workable regardless
of whether it can be implemented and whether the Italian government
says that it is required and works.
Well, it is
On 02/Dec/10 04:45, John Levine wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Authentication-Results Registration For Vouch By Reference Results'
draft-kucherawy-authres-vbr-01.txt as a Proposed Standard
The IESG plans to make
On 15/Dec/10 03:02, Marshall Eubanks wrote:
On Dec 14, 2010, at 6:07 PM, Robert Brockway wrote:
Eg, here is a link to a version of the IETF article from yesterday:
http://en.wikipedia.org/w/index.php?title=Internet_Engineering_Task_Forceoldid=390092590
Then (although this is the IESG's
I've never attended an IETF meeting. Why? Because it seems to me quite
unlikely to have a chance to say something useful by going there. I mean
useful with respect to a problem that I consider important. That is, not
just a minimal contribution to an already scheduled session that I may happen
On 10/Jan/11 15:08, Marshall Eubanks wrote:
What I would suggest (if this goes forward) is
- some space is set aside, ideally in or near the break area / room
- posters SHOULD be put up in the AM, starting at breakfast.
- the last refreshment break of the day, the authors are supposed
On 10/Jan/11 23:38, Fred Baker wrote:
Personally, call me stuck-in-the-mud, but this isn't an academic
conference in which grad students are advertising for a professor
that might be interested in mentoring them or a sponsor might fund
their research. This is an SDO, and internet drafts are
On 11/Jan/11 20:32, John C Klensin wrote:
--On Tuesday, January 11, 2011 10:35 -0800 Randy Presuhn
randy_pres...@mindspring.com wrote:
At issue though is that these individuals get paid
(sponsored) by someone, either directly or indirectly by
corporations and/or governments.
Not
On 19/Jan/11 05:23, ned+i...@mauve.mrochek.com wrote:
The client I'm using right now (which I coauthored) is one of the very few
with
support for external body dereferencing.
However, your client apparently omits to identify itself by means of a
User-Agent header field... Would you mind
I'm sorry I'm late, this thread was in my backlog.
On 12.03.2011 19:48, Dean Willis wrote:
On a related note, we've developed what we think is a secured mail
protocol suite. Yet we don't use it, instead subjecting our list members
(and more so the administrators) to having to deal with an
On 22.03.2011 18:53, Dean Willis wrote:
On Mar 22, 2011, at 10:23 AM, Alessandro Vesely wrote:
I think the IETF must substantiate its position against wiretapping by
providing alternative practical means to counter crime.
Weak security doesn't counter crime -- it creates it. For example
On 12/Apr/11 18:31, Phillip Hallam-Baker wrote:
Todd,
This is totally confused and you are completely wrong.
Under the Federal Election Campaign Act
http://en.wikipedia.org/wiki/Federal_Election_Campaign_Act, an
organization becomes a political committee by receiving
On 13/May/11 09:15, SM wrote:
This document covers RFC 4871 (4871bis actually), RFC 5451 and RFC
5617. The document specifies the circumstances under which the
capabilities discussed here are applicable. If the DKIM working group
decides on taking that path, it could ask for publication of
For an outsider's feedback about John's comments (1), (4), and (5):
On 31/May/11 18:23, John C Klensin wrote:
This proposal is problematic in several ways. The first is
obviously the most important, but the others suggest changes
that might be useful whether or not that main provision is
On 13/Jul/11 18:38, Marc Petit-Huguenin wrote:
On 07/13/2011 06:50 AM, Michael Richardson wrote:
Barry, I think that we should put a filter on the ietf.org that bounces
all messages with confidentiality notices.
Yes, and perhaps disclaimers/confidentiality notices should be standardized
On 14/Jul/11 03:48, John Levine wrote:
Yes, and perhaps disclaimers/confidentiality notices should be
standardized with their own MIME type to make automatic processing
easier so receivers of this kind of notice (mailing-list or other)
can respect the wishes of the sender.
That respect would of
On 14/Jul/11 18:37, Will McAfee wrote:
On Jul 14, 2011, at 11:28 AM, Alessandro Vesely ves...@tana.it wrote:
One can sign the Sensitivity header field defined by RFC 2156. It
can have the values Personal / Private / Company-Confidential.
However, I received some messages bearing
On 27/Jul/11 08:07, Samir Srivastava wrote:
Standards are developed by community for community. There is no
role of patent hunters in that.
I agree, with the exception of defensive patents, some of which are
announced with very elegant disclosures. Let's draw a veil over
incomprehensible and
On 26/Jul/11 06:19, Hector Santos wrote:
But the original destroyed signature from the author is not stripped.
Nor verified, apparently.
Authentication-Results: dkim.winserver.com;
dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
adsp=fail policy=all author.d=isdg.net
On 28/Jul/11 18:34, t.petch wrote:
The minor point is that e-mails have just got yet bigger. They are now
100-150%
bigger than when first I started following the IETF
According to Nielsen's Law, network connection speeds double every 21
months. DKIM is apparently using a quite reasonable
On 02/Aug/11 06:52, Hector Santos wrote:
Keith Moore wrote:
Repeat as needed; you can always partition the remaining part of
the problem again.
It was not a difficult problem. [...] how to scale the
authorization of 3rd party signer. [...] But there was a
fundamental mindset and
On 10.08.2011 08:58, SM wrote:
The reality is whatever the IETF thinks of the principles of Internet
architecture, operators will violate those principles when the latter
conflicts with their core value; which is about making money. In simple
terms, that protocol that has been designed to do
On 12.08.2011 21:02, Martin Rex wrote:
On 8/11/2011 9:37 AM, The IESG wrote:
The IESG has received a request from the Yet Another Mail WG (yam) to
consider the following document:
- 'Message Submission for Mail'
draft-ietf-yam-rfc4409bis-02.txt as a Full Standard
The IESG plans to make
On 30/Aug/11 04:50, Michel Py wrote:
The mechanism (ICMP redirects) is technically fine and socially not.
People have become paranoid and now they firewall everything. It is a
behavioral animal. I'm not saying it's a good idea; the market answer to
crossing firewalls is to encapsulate
On 04/Oct/11 17:28, Frank Ellermann wrote:
On 4 October 2011 16:17, Barry Leiba wrote:
I suggest using document instead of codify as this is not
being standardized.
That's a sensible change.
[Insert DEnglish disclaimer:] For document I read we say so, for
codify I read we say so, and
On 05/Oct/11 20:22, SM wrote:
The Abstract mentions that:
While not originally written as an Internet Draft, it has been
contributed to the IETF standards repository in order to make it
easier to incorporate this material into IETF work.
The no derivative clause makes it
On 21/Oct/11 09:06, t.petch wrote:
Thus to the mpls list, the mail travels at the speed of light
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com
(Postfix) with ESMTP id 9417311E80A5; Wed, 19 Oct 2011 13:49:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;
Hi Zoltan,
On 13/Jan/12 20:11, Zoltan Ordogh wrote:
I would like to start with a story.
A rather similar story is summarized here:
http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs
A bit later, a liaison statement was sent from OMA to IETF, seeking
collaboration and a “home” for the
work from this document if they just
abide by its boilerplate text, while the original post did not imply a
handoff of change control.
I apologize for any inconveniences that my action might have caused.
Regards
Alessandro Vesely
___
Ietf mailing list
Ietf
The solution is simple - move to TAI. That is the _true_ time, what
the master clocks actually keep. UTC is just a variant for creatures
living on the surface of the Earth.
Being one of those creatures, I voted for keeping leap seconds. UTC
seems to fit the global Internet quite nicely,
On 24/Feb/12 19:06, Scott Kitterman wrote:
On Friday, February 24, 2012 12:57:49 PM Andrew Sullivan wrote:
How could you integrate a pre-allocated type when you don't know what
its format is? If you knew how to do that, you could just deal with
unknown RRTPYEs, and then having TYPE99
On 27/Feb/12 21:30, Patrik Fältström wrote:
Yes, a pain. But...we just must be able to get new RRTypes
deployed. And not give up.
I agree it is a praiseworthy task to pursue the diffusion of unknown
RRTypes. However, it cannot be piggybacked on client protocols, that
have their own
On 29/Feb/12 02:54, ned+i...@mauve.mrochek.com wrote:
All that said, a suggestion: Patrik published a pretty good list of
most of the issues that arise when attempting to deploy new
RRTYPEs. Some of those, like the lack of GUI pulldowns in some
hosting provider web interfaces, are clearly
On 03/Mar/12 00:13, John R. Levine wrote:
Until provisoning systems accept UNKNOWN record types they will
always be a bottle neck. Without that you will have to wait for
the change request to be processed. Given the history just getting
records added to most of these system it will be
On 03/Mar/12 18:43, John Levine wrote:
Honestly, if new RR types were all text to be parsed by clients, a la
SPF and DKIM, that wouldn't be the worst thing in the world.
Well, since that's what is currently being done, it must obviously be
feasible. However, there is no reason to stick to it
On 05/Mar/12 18:09, John Levine wrote:
Sometimes an ASCII text record will be fine, in other cases, it probably
won't.
My point is as we move again towards multiple text representations of the
digit five for example,
both encoding and parsing is easier and more secure if that digit is really
On 06/Mar/12 04:56, ned+i...@mauve.mrochek.com wrote:
On 05/Mar/12 18:09, John Levine wrote:
Would you really want to build an SPF or DKIM parser into every
DNS server? That's a lot of code that the DNS manager doesn't
care about, but the mail manager does.
But it would be the same code,
On 06/Mar/12 16:00, John R. Levine wrote:
We seem to believe that the D part is deployed so that adding new
unknown RRTypes is not an issue.
I think this is correct, but OTOH someone recently asked about
possible issues in this area, and if I remember correctly,
received no response.
On 07/Mar/12 09:42, ned+i...@mauve.mrochek.com wrote:
It would still be possible to work around the need for a plugin, e.g.
by depending on some wizard web site, as in John's thought experiment.
For the rest of us, the possibility to install a plugin that takes
care of all the nitty-gritty
On Fri 11/May/2012 08:56:14 +0200 IETF Chair wrote:
We have identified space in Vancouver to hold the Bits and Bites event,
Would it be possible to design a _unified_ event board that mentions
_all_ the events at the location, including this one, WGs, BoFs, not
only IETF, but also IRTF, ISOC,
On 5 Jan 2012, todd glassey tglas...@earthlink.net wrote
On 1/5/2012 6:48 AM, Dave CROCKER wrote:
(One can quibble about the difference between algorithm and
program. An algorithm is a component of a program.
The program is the code-based implementation of the alg?
The distinction
On Tue 19/Jun/2012 00:44:25 +0200 Joe Touch wrote:
On 6/18/2012 3:30 AM, Alessandro Vesely wrote:
...
one can give a full description (or coding) of, say, sqrt, without
actually saying that the square of the result will match its argument
up to some rounding error. The specification does
On Thu 02/Aug/2012 03:28:38 -0700 Martin J. Dürst wrote:
In particular, the errata system is NOT meant to be used as an issue
tracker;
Of course we have mailing lists, issue trackers, and wikis, but the
problem is that none of them are for RFCs.
In addition, those tools seem to be
On Fri 03/Aug/2012 08:38:44 -0700 Barry Leiba wrote:
Easy would mean that people usually find them even if they're
not purposely looking for them. For example, the existence of an
approved errata could be signaled by coloring the margin near the
relevant text.
I like this idea. Not
On Tue 07/Aug/2012 15:20:35 +0200 t.p. wrote:
From: Yoav Nir y...@checkpoint.com
Would it make it easier to find if they were called notes or
corrections instead of errata?
Yes, corrections is what I see published in a newspaper to correct
errata in previous editions. So far, it is the
I wish to thank Phillip and Eric for their illuminating comments.
However, I'm still not clear on the role that great powers may play in
the standards development and deployment, compared to that of vested
interests. Stranger to economics, I may be conflating the concept of
open standard with
On Mon 13/Aug/2012 03:22:52 +0200 JFC Morfin wrote:
At 19:16 11/08/2012, John C Klensin wrote:
On the other hand, irrational behavior would be nothing new in this
area so I can't disagree with the possibility.
Correct. This is why, if I understand the motivation, I strongly
disagree with
On Wed 29/Aug/2012 11:54:02 +0200 Noel Chiappa wrote:
From: Stephane Bortzmeyer bortzme...@nic.fr
I strongly regret that Commerce has a specific mention, among all the
other uses of the Internet. The network is not only open for business!
I hear you, but unless the Internet were a
The first paragraph says:
Internet-Drafts (I-Ds) are working documents of the IETF, its Areas,
and its Working Groups. In addition, other groups, including the IAB
and the IRTF Research Groups, distribute working documents as I-Ds.
After all the groups, I'd add and individuals.
On Tue
find out
that that assumption was wrong. As it formally licenses the work,
that boilerplate text may make the difference between fair use and
infringement of an exclusive right of the copyright owner --IANAL.
On Sep 4, 2012, at 7:20 AM, Alessandro Vesely wrote:
On Tue 04/Sep/2012 03:29:00 +0200 Sam
On Wed 05/Sep/2012 21:59:56 +0200 John C Klensin wrote:
--On Wednesday, September 05, 2012 11:02 -0700 SM s...@resistor.net wrote:
At 09:04 05-09-2012, Brian E Carpenter wrote:
That's an interesting but not very informative statement.
:02 -0700
To: Alessandro Vesely ves...@tana.it
Cc: lead...@internetsociety.org, Public Software Mailing List
pubs...@elists.isoc.org
Subject: Re: The Internet Society Fellowship to the IETF
Dear Mr. Vesely,
Thank you for your email regarding the ISOC Fellowship to the IETF
Programme. This specific
On Tue 23/Oct/2012 01:49:41 +0200 The IAOC wrote:
We have tried to contact Marshall over this time period [...]
We think this process was not intended to be used when a sitting IAOC,
IESG, or IAB member vacates his/her position. We believe that the
intended use of this process was for
On Thu 01/Nov/2012 18:31:47 -0400 Russ Housley wrote:
A formal policy requires IETF consensus, and it would be published
as a BCP in the RFC series.
Isn't that's something the IETF will have do in any case, sooner or later?
AFAICU, standardization is about establishing the competition rules.
On Wed 28/Nov/2012 16:18:05 +0100 Keith Moore wrote:
On 11/27/2012 01:00 PM, Barry Leiba wrote:
This brings up a question that I have as an AD: A number of times
since I started in this position in March, documents have come to
the IESG that prompted me (or another AD) to look into the
On Thu 06/Dec/2012 13:36:07 +0100 Dave Cridland wrote:
In general, there are a number of technical standards and protocols
which are useful, or essential, for IETF participation; documenting
these in a single location would seem beneficial.
Don't forget the confidentiality notices conundrum,
On Wed 12/Dec/2012 20:31:04 +0100 Yaron Sheffer wrote:
I have just published a draft that proposes an alternative to
Stephen's fast track. My proposal simply allows authors to document,
in a semi-standard way, whatever implementations exist for their
protocol, as well as their
On Fri 14/Dec/2012 09:49:30 +0100 Yaron Sheffer wrote:
to clarify, my proposal only applies to Internet Drafts, and clearly
states that the implementation section should be removed from the
document before it is published as RFC.
One place where an Implementation Status may help is IETF LCs:
On Tue 01/Jan/2013 09:31:28 +0100 Brian E Carpenter wrote:
** CCITT document D.1. The 1988 version includes the restrictions on
use of leased lines:
http://www.itu.int/rec/dologin_pub.asp?lang=eid=T-REC-D.1-198811-S!!PDF-Etype=items
The 1991 version is much less restrictive, but it remains
The Encrypted Media Extensions (EME, a.k.a. DRM in HTML5)
specification is not a real DRM itself. It provides for add-on parts
described as Content Decryption Modules that provide DRM functionality
for one or more Key Systems. DRMs are obviously designed to be
non-interoperable, and EME is a
On Fri 26/Apr/2013 02:53:58 +0200 Mark Nottingham wrote:
Personally, I don't have a firm position on these issues, but I couldn't let
this pass by.
On 25/04/2013, at 7:38 PM, Alessandro Vesely ves...@tana.it wrote:
DRMs are obviously designed to be non-interoperable, and EME is a
standard
On Fri 26/Apr/2013 21:59:52 +0200 Brian E Carpenter wrote:
3. EME should have a very low or zero cost of entry for a content provider.
Quoting from a commenter on The Register:
The DRM mechanism must allow *individuals* (or small groups) a
low-cost low-hassle way to use it. That's because
On Tue 30/Apr/2013 01:07:42 +0200 Mark Andrews wrote:
The really annoying thing is that SPF is techically superior
to TXT is lots of ways.
1. It uniquely identifies the roll of the record.
2. As SPF records are singletons you don't need to identify
and
On Tue 30/Apr/2013 21:54:11 +0200 David Conrad wrote:
On Apr 30, 2013, at 11:12 AM, Dave Crocker d...@dcrocker.net wrote:
What is the IETF-approved timeframe in which the market is
allowed to accept/reject a particular technology?
I've no idea what the lower limit is or should be, but I'm
On Tue 30/Apr/2013 19:11:15 +0200 Doug Barton wrote:
On 04/30/2013 09:28 AM, Alessandro Vesely wrote:
While it's too late for SPF, we can learn this lesson.
As has been repeatedly pointed out in the discussion on both dnsext
and spfbis, it is NOT too late for SPF. The way forward is simple
On Tue 30/Apr/2013 20:02:11 +0200 Edward Lewis wrote:
On Apr 30, 2013, at 12:28, Alessandro Vesely wrote:
...The basic fact that killed the SPF type is the ability to use
TXT as a replacement. There must be an analogous of Gresham's
law: Bad types drive out good ones.
I disagree
On Wed 01/May/2013 03:04:52 +0200 Mark Andrews wrote:
In message 517ff144.5040...@tana.it, Alessandro Vesely writes:
On Tue 30/Apr/2013 01:07:42 +0200 Mark Andrews wrote:
SPF is techically superior to TXT is lots of ways.
[...]
For TXT you need to lookup the existing RRset, extract
1 - 100 of 197 matches
Mail list logo
