[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Moving along with the INFO discussion
Good news: #5 exactly the mechanism RFC 5022 uses. Brilliant (or
toasted) minds think alike.
Bad news: it does not solve the interoperability problem in its
entirety. It means that the MSCML endpoints are sure they understand
each other. However, if some one *also* does Cisco DTMF INFO, there is
no way of signaling that, or that a particular INFO message is MSCML
or DTMF, other than for the fact the Content-Type *hopefully* will be
different.
Note Content-Type is not enough to solve the problem in the abstract,
although it works for the known usages. That means I would NOT
advocate relying on Content-Type to disambiguate INFO messages.
On Jul 15, 2008, at 7:19 PM, Dean Willis wrote:
We had a large, long, and lengthy thread of discussion that I will try
to summarize.
So far, almost everybody who has voiced an opinions says we need to
fix,
rather than deprecate, INFO.
Opinions on fixing it vary.
Most people seem to think we need a registry of INFO usages that will,
at the very least, give us a table of the existing usages and the RFCs
or other specs that define them.
The sticky point of discussion is a negotiation and discovery
mechanism.
We've had on-list proposals for a strong mechanism based on the mode
used in RFC 3265.
From sip-bounces at ietf.org Mon Jul 28 02:50:15 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id B54EB3A6910;
Mon, 28 Jul 2008 02:50:15 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 2AFDA3A68C8
for <sip at core3.amsl.com>; Mon, 28 Jul 2008 02:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.588,
BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id dnOvSNRlkeLx for <sip at core3.amsl.com>;
Mon, 28 Jul 2008 02:50:14 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com
[66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 3F2483A6809
for <sip at ietf.org>; Mon, 28 Jul 2008 02:50:14 -0700 (PDT)
Received: from [130.129.20.50] (port=51661)
by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128)
(Exim 4.68) (envelope-from <eburger at standardstrack.com>)
id 1KNPMv-0006z1-Oc; Mon, 28 Jul 2008 02:50:18 -0700
Message-Id: <2793641C-8728-4CFD-A760-DDAB9A1F8FAA at standardstrack.com>
From: Eric Burger <eburger at standardstrack.com>
To: Dean Willis <dean.willis at softarmor.com>
In-Reply-To: <487CEA48.6090605 at softarmor.com>
Mime-Version: 1.0 (Apple Message framework v926)
Date: Mon, 28 Jul 2008 10:50:14 +0100
References: <487CEA48.6090605 at softarmor.com>
X-Mailer: Apple Mail (2.926)
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: SIP IETF <sip at ietf.org>
Subject: Re: [Sip] Moving along with the INFO discussion
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
Good news: #5 exactly the mechanism RFC 5022 uses. Brilliant (or
toasted) minds think alike.
Bad news: it does not solve the interoperability problem in its
entirety. It means that the MSCML endpoints are sure they understand
each other. However, if some one *also* does Cisco DTMF INFO, there is
no way of signaling that, or that a particular INFO message is MSCML
or DTMF, other than for the fact the Content-Type *hopefully* will be
different.
Note Content-Type is not enough to solve the problem in the abstract,
although it works for the known usages. That means I would NOT
advocate relying on Content-Type to disambiguate INFO messages.
On Jul 15, 2008, at 7:19 PM, Dean Willis wrote:
We had a large, long, and lengthy thread of discussion that I will try
to summarize.
So far, almost everybody who has voiced an opinions says we need to
fix,
rather than deprecate, INFO.
Opinions on fixing it vary.
Most people seem to think we need a registry of INFO usages that will,
at the very least, give us a table of the existing usages and the RFCs
or other specs that define them.
The sticky point of discussion is a negotiation and discovery
mechanism.
We've had on-list proposals for a strong mechanism based on the mode
used in RFC 3265.
Some folSome folks think we need to do this, and others thing there's no
reason
to bother since it is not likely to get implemented because just
inventing a non-standard INFO use is easier.
Is there a middle ground?
What if we were to:
1) Establish an INFO registry and register our existing usages, policy
either "first come, first served" or "Specification required".
2) Define an Info-type header field and register (in the regoistry of
#1) a value for each known Info usage. Fully-compliant implementations
would send an Info-type header field with the appropriate value in
every
INFO message.
3) Require registration of an Info-type for each future usage into the
registry of #1 above.
4) Define an "Info-type not supported" error response message. This
handles the use case of a UAS that receives an INFO with an Info-
type it
does not understand.
5) For Info-types for which discovery is required, use a standards-
track
RFC to define a SIP extension and option tag, and use the usual
OPTIONS/Require negotiation mechanism for discovery. We might consider
revising each INFO-using RFC to define an appropriate option tag.
This lets people easily register INFO usages and a corresponding
Info-type tag. It lets nodes that don't understand an Info-type usage
reject the message (at the expense of whacking the dialog, which
arguably was already in need of whacking). And it provides a standard
(although heavy) mechanism for discovery and negotiation when those
are
required.
I think the above addresses the major concerns, is reasonably
implementable, is reasonably operable, and requires the smallest
possible effort to document. It's also pretty much backward
compatible.
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
ks think we need to do this, and others thing there's no
reason
to bother since it is not likely to get implemented because just
inventing a non-standard INFO use is easier.
Is there a middle ground?
What if we were to:
1) Establish an INFO registry and register our existing usages, policy
either "first come, first served" or "Specification required".
2) Define an Info-type header field and register (in the regoistry of
#1) a value for each known Info usage. Fully-compliant implementations
would send an Info-type header field with the appropriate value in
every
INFO message.
3) Require registration of an Info-type for each future usage into the
registry of #1 above.
4) Define an "Info-type not supported" error response message. This
handles the use case of a UAS that receives an INFO with an Info-
type it
does not understand.
5) For Info-types for which discovery is required, use a standards-
track
RFC to define a SIP extension and option tag, and use the usual
OPTIONS/Require negotiation mechanism for discovery. We might consider
revising each INFO-using RFC to define an appropriate option tag.
This lets people easily register INFO usages and a corresponding
Info-type tag. It lets nodes that don't understand an Info-type usage
reject the message (at the expense of whacking the dialog, which
arguably was already in need of whacking). And it provides a standard
(although heavy) mechanism for discovery and negotiation when those
are
required.
I think the above addresses the major concerns, is reasonably
implementable, is reasonably operable, and requires the smallest
possible effort to document. It's also pretty much backward
compatible.
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip