Re: Second Last Call: <draft-ietf-sieve-notify-sip-message-08.txt> (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
Hector <sant9442@gmail.com> Thu, 26 January 2012 23:01 UTC
Return-Path: <sant9442@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BF721F8707 for <ietf@ietfa.amsl.com>; Thu, 26 Jan 2012 15:01:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koUTfAjVDfqs for <ietf@ietfa.amsl.com>; Thu, 26 Jan 2012 15:01:54 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E6CD321F86C2 for <ietf@ietf.org>; Thu, 26 Jan 2012 15:01:53 -0800 (PST)
Received: by ggnq4 with SMTP id q4so644111ggn.31 for <ietf@ietf.org>; Thu, 26 Jan 2012 15:01:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=zah50Ew5O/FgjJY7Y4IZia2i+ImD4qgRc+4JSL+6pyI=; b=IFgfp6yJKbc/A9EXHgnUwuXSIgEzxhi19hG+vSChCJGwyM04N0PxbN8LPt58QY4cfV vW8pJQ3bUcH7DdhghOSMfOam5iC00G6TtDraDj7es7aW2LST3DdD5d5taqPR4GZTelFr WyvthSQPrOb63YC1op5BpIlhf+RmdahvKVFDU=
Received: by 10.236.154.232 with SMTP id h68mr6782714yhk.51.1327618897729; Thu, 26 Jan 2012 15:01:37 -0800 (PST)
Received: from adsl-215-50-126.mia.bellsouth.net (99-3-147-93.lightspeed.miamfl.sbcglobal.net. [99.3.147.93]) by mx.google.com with ESMTPS id o9sm9433874yhk.20.2012.01.26.15.01.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jan 2012 15:01:36 -0800 (PST)
Message-ID: <4F21DB61.3000201@gmail.com>
Date: Thu, 26 Jan 2012 18:01:53 -0500
From: Hector <sant9442@gmail.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: Second Last Call: <draft-ietf-sieve-notify-sip-message-08.txt> (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com>, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> <CD5674C3CD99574EBA7432465FC13C1B226F573BC9@DC-US1MBEX4.global.avaya.com>, <4F208AEF.5060406@qualcomm.com> <CD5674C3CD99574EBA7432465FC13C1B226F573BCE@DC-US1MBEX4.global.avaya.com> <4F21ABF2.7040002@qualcomm.com> <6842.1327617385@marajade.sandelman.ca>
In-Reply-To: <6842.1327617385@marajade.sandelman.ca>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jan 2012 23:01:55 -0000
Michael Richardson wrote: >>>>>> "Pete" == Pete Resnick <presnick@qualcomm.com> writes: > Pete> decision about what ought to be done here. The community needs > Pete> to come to a consensus about the right outcome and the > Pete> leadership folks will judge that consensus and instantiate > Pete> whatever actions need to be taken. It's certainly OK if you > > At this point, I do not have a clear idea of what the set of outcomes > could be. I think that they can include: > 1) not publishing the document. > 2) revising the document to remove/work-around the encumbered work > 3) some legal action to attend to anul the patent (which might or > might not succeed). > 4) go ahead and publish things as they are. > > > I am concerned that the individual may be scapegoated here, but I also > do not buy that they didn't understand things. > The company spent money to file a patent, and they hired someone to do > this, and they certainly knew where the "invention" was documented. > > There is a need for a consequence for not following the IPR. > I read the document, but not the patent, so I don't see what's so novel > about it all, and I also don't know how hard it would be to work around. > > My preference is to some method to remove any value the patent might > have. +1. Given the nature of the new 1996 timeline for patentability of prior art, the richness of technologies, the integration of technologies. e.g. the Markus Analysis does not apply as strong as it did which in short, says the following (paraphrasing from my old Westinghouse Chief Lawyer presentation to the Venture Group): - You can not take prior art A, B and create a patent D, unless there is a new and unique part C, - Given the first rule, parts A and B can not be restricted on existing systems and/or deny existing systems to implement what would be natural course of their existence. IOW, if a Markus Analysis shows that Part C is a natural evolution of the existing systems, they can not denied adding it. This is what has me to sleep like a baby with the new frivolous patents of prior arts that is now allowed. Unfortunately, what has allowed the new patent era to exist is the less emphasis of performing the Markus Analysis by patent examiners. Overall, the mere fact of submitting an IETF document, by definition, it means implementators are not subject to any sort of restrictions. As it is right now, when I see new I-D comes in, if it even smells like its has IPR related stuff, I totally 100% skip it. Ignore it. I don't bother with it. In my view, the IETF should view new submissions in the same way. So its not only a, "Are you totally sure this is IPR-claim-free?" but also "Are you using IETF related parts? Because if the I-D submitter is using existing IETF parts, then he/she must be aware that any IPR existing or in the future against anyone that exist using such parts or now also include future system that decides to use the new I-D. In my view, Mr. Resnick, should consider the concept of the Markus Analysis. If this I-D is allowed to go thru, how will it alter existing systems? Will existing systems with all the parts, except the integration of the new by existing part, be denied the natural inclusion of the new part? In other words, a system that has IETF technology SMTP and/or IMAP and SIEVE already in place, if they add an existing IETF technology SIP, will they be restricted? There has to be something completely novel and not an IETF technology for it to hold any strength. But if that is not the case, where each part is an IETF technology, the mere integration of all these IETF parts, by definition, must not have any sort of patent strength or for that matter, recognition. -- Sincerely Hector Santos http://www.santronics.com jabber: hector@jabber.isdg.net
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Adam Roach
- RE: Second Last Call: <draft-ietf-sieve-notify-si… Adrian Farrel
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Peter Saint-Andre
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Thomas Nadeau
- Re: Second Last Call: <draft-ietf-sieve-notify-si… SM
- RE: Second Last Call: <draft-ietf-sieve-notify-si… Worley, Dale R (Dale)
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Peter Saint-Andre
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Pete Resnick
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Pete Resnick
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Adam Roach
- Violation of IETF process (was: Second Last Call:… SM
- RE: Violation of IETF process (was: Second Last C… Adrian Farrel
- Re: [sieve] Second Last Call: <draft-ietf-sieve-n… Dave CROCKER
- RE: Violation of IETF process (was: Second Last C… SM
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Dave Cridland
- Re: Second Last Call: <draft-ietf-sieve-notify-si… John C Klensin
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Harald Alvestrand
- Re: [sieve] Second Last Call: <draft-ietf-sieve-n… Bob Hinden
- Re: Second Last Call: <draft-ietf-sieve-notify-si… John C Klensin
- RE: Second Last Call: <draft-ietf-sieve-notify-si… Murray S. Kucherawy
- RE: Violation of IETF process (was: Second Last C… Murray S. Kucherawy
- RE: Second Last Call: <draft-ietf-sieve-notify-si… Murray S. Kucherawy
- RE: Second Last Call: <draft-ietf-sieve-notify-si… Murray S. Kucherawy
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Pete Resnick
- Re: Second Last Call: <draft-ietf-sieve-notify-si… SM
- Re: Second Last Call: <draft-ietf-sieve-notify-si… John C Klensin
- encouraging compliance with IPR disclosure rules Peter Saint-Andre
- RE: Second Last Call: <draft-ietf-sieve-notify-si… Worley, Dale R (Dale)
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Pete Resnick
- Re: encouraging compliance with IPR disclosure ru… SM
- Re: Violation of IETF process todd glassey
- Re: Second Last Call: <draft-ietf-sieve-notify-si… todd glassey
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Kevin P. Fleming
- Re: Second Last Call: <draft-ietf-sieve-notify-si… SM
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Martin Rex
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Cyrus Daboo
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Cyrus Daboo
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Michael Richardson
- RE: Second Last Call: <draft-ietf-sieve-notify-si… Murray S. Kucherawy
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Hector
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Pete Resnick
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Barry Leiba
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Ted Hardie
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Steven Bellovin
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Barry Leiba
- Re: Second Last Call: <draft-ietf-sieve-notify-si… SM
- RE: Second Last Call: <draft-ietf-sieve-notify-si… Murray S. Kucherawy
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Hector Santos
- Re: Second Last Call: <draft-ietf-sieve-notify-si… t.petch
- Re: [sieve] Second Last Call: <draft-ietf-sieve-n… Arnt Gulbrandsen
- Re: encouraging compliance with IPR disclosure ru… Polk, William T.
- Re: encouraging compliance with IPR disclosure ru… Scott Brim
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Dave CROCKER
- Re: Second Last Call: <draft-ietf-sieve-notify-si… Alexey Melnikov
- Re: encouraging compliance with IPR disclosure ru… todd glassey