Re: SIP API spec

Noel Chiappa <> Wed, 27 January 1993 23:33 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa06154; 27 Jan 93 18:33 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06150; 27 Jan 93 18:33 EST
Received: from Sun.COM by CNRI.Reston.VA.US id aa04200; 27 Jan 93 18:36 EST
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA19366; Wed, 27 Jan 93 15:33:27 PST
Received: from sunroof.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA01491; Wed, 27 Jan 93 15:34:38 PST
Received: from Eng.Sun.COM (engmail1) by sunroof.Eng.Sun.COM (4.1/SMI-4.1) id AA20570; Wed, 27 Jan 93 15:33:05 PST
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA25092; Wed, 27 Jan 93 15:34:36 PST
Received: from by Sun.COM (4.1/SMI-4.1) id AA19268; Wed, 27 Jan 93 15:32:59 PST
Received: by id AA29437; Wed, 27 Jan 93 18:31:20 -0500
Date: Wed, 27 Jan 93 18:31:20 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Noel Chiappa <>
Message-Id: <>
Subject: Re: SIP API spec
Content-Length: 1025

    I would not like to reopen the "flow-id" debate just now, but the only thing
    we could agree upon was to let it "for further study". There are two extreme
    positions on this, which I could briefly portrait as "datagram" and "virtual
    As I said, we will probably not solve the question now. Which is why I find
    Bob's spec entirely acceptable -- it merely says "here are the bits that
    should go in the next packets".

Aren't you worried that if you don't specify the semantics, either a) different
people will write and deploy code that interprets the field in different ways,
leading to interoperation problems down the line, or b) you will find that the
syntax you have do not supprt the semantics you need (as is the case with the
current IP TOS field)?

I am getting the feeling that this specification is being thrown together in a
real hurry in an attempt to 'win' some competition. I can't help but feel that
this is the wrong road to take to produce a great design....