Re: Protocol Definition

Abdussalam Baryun <abdussalambaryun@gmail.com> Mon, 18 June 2012 13:18 UTC

Return-Path: <abdussalambaryun@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 8C68721F85A2 for <ietf@ietfa.amsl.com>; Mon, 18 Jun 2012 06:18:03 -0700 (PDT)
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=[AWL=0.000, 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 agh0ZTjkjWsi for <ietf@ietfa.amsl.com>; Mon, 18 Jun 2012 06:18:03 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB1C621F8595 for <ietf@ietf.org>; Mon, 18 Jun 2012 06:18:02 -0700 (PDT)
Received: by vcqp1 with SMTP id p1so2995094vcq.31 for <ietf@ietf.org>; Mon, 18 Jun 2012 06:18:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=vlULzs853aLD93J2MpQwNqC9rhyy8tHN5mK49AzCUHo=; b=oKBqz6bthpmxYN9NnrWv1m4/ZwsKc6QXB9MVFpuAfKv3E1qz8dr3bFphyVKT2pvMl7 1RBhGra33Sq6zHp52OlFdldJPidBo+vxJ3lSoXERzFWNUk5aT0334nL+vE6WsWBB/UF9 ME933KddCJuHaq+8vEtDkXHmGhOyxCrhzl1TO5M9nmsEXwIf+yBX409QtM7I2zfELH3C 5CSx7gOAjMVx7KptfHy6yqmgRzr43LKXxHFta2iLZ9jzanEbrlWywgzaCtT1A5TDYgJZ KDcx/aJof5OI1RCO2w30KnBc4tb85KnXPxHdxwnbnHyTpDXC3Ats5CguxNn/7XlM2yi9 Y8YA==
MIME-Version: 1.0
Received: by 10.220.149.148 with SMTP id t20mr7801422vcv.12.1340025482367; Mon, 18 Jun 2012 06:18:02 -0700 (PDT)
Received: by 10.220.211.72 with HTTP; Mon, 18 Jun 2012 06:18:02 -0700 (PDT)
Date: Mon, 18 Jun 2012 15:18:02 +0200
Message-ID: <CADnDZ8_5nH7gNvR_LAB3wJ0zfKh-G0WmWbTm6yDq-M+LMajfbg@mail.gmail.com>
Subject: Re: Protocol Definition
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: vesely@tana.it
Content-Type: text/plain; charset="ISO-8859-1"
Cc: ietf <ietf@ietf.org>
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: Mon, 18 Jun 2012 13:18:03 -0000

IMO the important issue in any definition is to include how the IETF
defines protocol,
this may be find in some RFCs :)

The IP is the main protocol, and all protocols in IETF are based on IP
and Internet.

AB
++++

On 5 Jan 2012, todd glassey <tglassey at 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 is relevant here because a protocol is typically
>> a complete mechanism rather than being a component of the
>> mechanisms.
>
> I.e. "A complete method of doing something"...

I noticed no disagreement between "method" and "mechanism", at the
time.  In retrospect, those two terms might seem to allude to a
different depth of semantic explanations.  Rereading that thread, I
find that the same ambiguity holds for algorithm descriptions:  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 not have to relate
the underlying mathematical abstraction.

Protocol specifications, especially when dealing with policies, do not
have to describe the exact meaning of the relevant tokens.  To do that
would often look like mandating a state or a reaction, neither of
which is needed to ensure interoperability.  In fact, the protocol
just has to ensure that a policy can be transmitted correctly.  Many
would rather leave a policy token underspecified than get involved in
its details.

In that respect, a protocol is not a complete method.  The "upper
layer", where policies and politics are dealt with, seems to be too
fuzzy to be specified.  I think this limitation is consistent with the
etymological meaning of the term, that refers to forms of conduct that
don't betray intentions.  Is that right?