John C Klensin wrote:
> if you have wild and wonderful new features, write drafts,
> introduce them as separate, Proposed Standard, updates to
> 2821 that stand on their own, with their own justifications.
For one of the two discussed proposals, nullmx, that would be
easy enough, an old I-D exist
On 2008-03-28 18:49 Ray Pelletier said the following:
> The Trustees adopted the Non-Profit Open Software License 3.0 in
> September 2007 as the license it would use for open sourcing software
> done as work-for-hire and that contributed to it, at that time thinking
> of code contributed by IE
On 2008-03-28 20:14, Olaf Kolkman wrote:
>
> On Mar 27, 2008, at 10:28 PM, Brian E Carpenter wrote:
>> While not really disagreeing with Leslie and Olaf, I would
>> point out that the IPR WG was chartered to look at
>> IETF documents.
>
> Those being ietf-stream exclusively or implicitly also cov
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-sieve
+1. I couldn't express it better.
Brian
On 2008-03-29 04:54, Ted Hardie wrote:
> At 8:16 AM -0700 3/28/08, Simon Josefsson wrote:
>> "Joel M. Halpern" <[EMAIL PROTECTED]> writes:
>>
>>> I do not understand the problem you want addressed. The way this is
>>> worded, it doesn't matter what "ope
> Ned Freed wrote:
> > this entire exercise is focused on a move to draft with this revision
> In this case I'm a part of the rough, my focus is on "get it right"
> before the staus. For 2822upd I'd be upset if it is no STD in 2010,
> 2821bis is different.
I completely and categorically disagr
Lawrence Rosen wrote:
> Margaret Wasserman wrote:
>> Disclaimer: IANAL, and I apologize if I am misunderstanding
>> something about the license you referenced, but...
>>
>> It seems to me that the "Non-Profit Open Software License 3.0", while
>> fine for the source code to IETF tools, places more
The agreement was to let the trust work out the legal details. This
document is intended to tell the trust what we want, clearly and
unambiguously. The current text is unambiguous. If we start trying to
say that this or that specific license is a good starting point, then
they have to figure
> c) to distribute or communicate copies of the Original Work
> and Derivative Works to the public, with the proviso that
> copies of Original Work or Derivative Works that You
> distribute or communicate shall be licensed under this
> Non-Profit Open Software License or as provided in section
Margaret Wasserman wrote:
> Disclaimer: IANAL, and I apologize if I am misunderstanding
> something about the license you referenced, but...
>
> It seems to me that the "Non-Profit Open Software License 3.0", while
> fine for the source code to IETF tools, places more restrictions and
> more burd
[EMAIL PROTECTED] wrote:
> Let me throw another idea into the mix. What if we were to
> recommend a transition architecture in which an MTA host
> ran two instances of the MTA software, one binding only to
> IPv4 addresses, and the other binding to only IPv6 addresses.
> Assume that there will be
Ray Pelletier wrote:
> The Trustees adopted the Non-Profit Open Software License 3.0 in
> September 2007 as the license it would use for open sourcing software
> done as work-for-hire and that contributed to it, at that time thinking
> of code contributed by IETF volunteers. See:
> http://truste
--On Friday, 28 March, 2008 19:20 +0100 Frank Ellermann
<[EMAIL PROTECTED]> wrote:
>> a move to draft is not the time to introduce new features.
>
> It's a trick to keep wild and wonderful new features out. For
> the IPv6-fallback discussed in this thread "getting it right"
> is more important
I would think that any license for RFC code should meet two
requirements:
1) It should be usable by anyone in the open source community
(compatible
with any open source/free software license).
2) It should be usable by anyone in any corporation who sells a closed
source product.
That way,
SM wrote:
> At 03:01 28-03-2008, Simon Josefsson wrote:
>
>> To give the Trust something concrete to work with I propose to add the
>> following:
>>
>> To make sure the granted rights are usable in practice, they need to
>> at least meet the requirements of the Open Source Definition [OSD],
>>
Ray Pelletier wrote:
> The Trustees adopted the Non-Profit Open Software License 3.0 in
> September 2007 as the license it would use for open sourcing
> software done as work-for-hire and that contributed to it, at that
> time thinking of code contributed by IETF volunteers. See: http://
At 03:01 28-03-2008, Simon Josefsson wrote:
>Regarding -outbound section 4.3:
>
>
>As such, the rough consensus is that the IETF Trust is to grant
>rights such that code components of IETF contributions can be
>extracted, modified, and used by anyone in any way desired. To
>enable
Ned Freed wrote:
> this entire exercise is focused on a move to draft with this revision
In this case I'm a part of the rough, my focus is on "get it right"
before the staus. For 2822upd I'd be upset if it is no STD in 2010,
2821bis is different.
> a move to draft is not the time to introduc
Ray Pelletier wrote:
>
> Peter Saint-Andre wrote:
>
>> Joel M. Halpern wrote:
>>
>>
>>> I do not understand the problem you want addressed. The way this is
>>> worded, it doesn't matter what "open source" or "free software" is or
>>> becomes. The intention is to grant anyone to do anything wi
Peter Saint-Andre wrote:
Joel M. Halpern wrote:
I do not understand the problem you want addressed. The way this is
worded, it doesn't matter what "open source" or "free software" is or
becomes. The intention is to grant anyone to do anything with the code
segments. That's what we ask
Joel M. Halpern wrote:
> I do not understand the problem you want addressed. The way this is
> worded, it doesn't matter what "open source" or "free software" is or
> becomes. The intention is to grant anyone to do anything with the code
> segments. That's what we ask the trust to do. Further
> On Thu, 27 Mar 2008, Matti Aarnio wrote:
> >
> > There will be lots of legacy codes using legacy APIs for long future.
> > I do use getaddrinfo() API myself, and permit it do all queries to
> > get addresses. Thus it will also query for A in addition to .
> > It can even be ordered to ign
> > > > In an IETF that believes the potential recursion of URNs and
> > > > NAPTR records is reasonable, it is really hard for me to get
> > > > excited about that one possible extra lookup. YMMD, of course.
> >
> > I can't get excited about this either.
> >
> > > Doug's issue, which sparked
At 8:16 AM -0700 3/28/08, Simon Josefsson wrote:
>"Joel M. Halpern" <[EMAIL PROTECTED]> writes:
>
>> I do not understand the problem you want addressed. The way this is
>> worded, it doesn't matter what "open source" or "free software" is or
>> becomes. The intention is to grant anyone to do anyt
>> and the dummy SMTP server works, but it consumes resources on the
>> host and eats bandwidth on the network. having a way to say "don't
>> send this host any mail" in DNS seems like a useful thing. and we
>> simply don't need the fallback to because we don't have the
>> backward
"Joel M. Halpern" <[EMAIL PROTECTED]> writes:
> I do not understand the problem you want addressed. The way this is
> worded, it doesn't matter what "open source" or "free software" is or
> becomes. The intention is to grant anyone to do anything with the code
> segments. That's what we ask
--On Wednesday, 26 March, 2008 17:09 + Tony Finch
<[EMAIL PROTECTED]> wrote:
>> With that change to "address record", if no MX record is
>> found, the SMTP client is required to look for DNS names with
>> either A or RRs, rather than A RRs only.
>
> There's also RFC 3974 (Jan 2005, inf
I do not understand the problem you want addressed. The way this is
worded, it doesn't matter what "open source" or "free software" is or
becomes. The intention is to grant anyone to do anything with the code
segments. That's what we ask the trust to do. Further in line.
Simon Josefsson wrot
> My suggestion is to rewrite section 4 a bit to call out that this
> document does not cover the incoming rights for the independent and
> irtf stream and to use the terms "ietf-stream" and possibly "iab-
> stream" in the definitions.
thats all well & good for the independent stream since t
Simon Josefsson wrote:
> To give the Trust something concrete to work with I propose to add the
> following:
>
> To make sure the granted rights are usable in practice, they need to
> at least meet the requirements of the Open Source Definition [OSD],
> the Free Software Definition [FSD], an
On Mar 27, 2008, at 8:31 PM, Keith Moore wrote:
> David Morris wrote:
>>
>> Perhaps you could help us out and share a reference to
>> documentation of such problems. I for one have not personally
>> observed any problems related to using the A record to locate a
>> mail server when there is
> >> OTOH, I think standardizing this convention makes all
> sorts of sense,
> >> but not, of course, in 2821bis.
> >
> > Why not in 2821bis? Is 2821bis really that time critical?
>
> It is on its way to Draft Standard. This would be a
> sufficiently new feature to force recycle at Propo
> For issues noted, for each I'd like to ask quostions such as:
> - was this noticed in the testbed? how?
> - was the issue relevant in that context; if not, why not?
> - if the issue was noticed, how was it worked around? which
>approaches worked (in that restricted context), which did n
On Fri, 28 Mar 2008, Jari Arkko wrote:
> This would be very useful addition to the document. Authors?
>
> But note that the overall experience from the specific approach chosen
> here was that yes, its possible get it to working, but there are
> significant issues both for deployment and for the wa
Regarding -outbound section 4.3:
IETF contributions often include components intended to be directly
processed by a computer. Examples of these include ABNF definitions,
XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values,
MIBs, ASN.1, or classical programming code. Thes
Thanks for your review, Pekka. A few notes:
> it doesn't go into much detail on how they solved
> difficult and more interesting issues, for example:
> - how they solved MTU problems caused by adding hop-by-hop header
> - given their deployment model, why didn't they try inserting a destinati
On Mar 27, 2008, at 10:28 PM, Brian E Carpenter wrote:
While not really disagreeing with Leslie and Olaf, I would
point out that the IPR WG was chartered to look at
IETF documents.
Those being ietf-stream exclusively or implicitly also covering the
iab-stream?
Personally, I think it makes
37 matches
Mail list logo