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