[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Moving along with the INFO discussion
Must be different registries for all the reasons JDR & Paul mention.
I am torn on the Proprietary Registry, however. We *think* we know
all the bizarre ways people use INFO in the world, but I am constantly
surprised by some of the "unique" things that get discussed on the SIP
Forum Discussion list. On the one hand, we would want to have an open
call for proprietary implementations so we can register and analyze
them. On the other hand, one could see how that could encourage new,
yet obsolete, INFO usages.
Given that at least two of the extant INFO I-D's enumerate the classes
of INFO usage in the wild, is there ANY value to a Proprietary INFO
Registry?
On Jul 15, 2008, at 11:36 PM, Jonathan Rosenberg wrote:
I agree with Paul; these need to be different registries.
I also agree that inventing a new info framework will NOT make us
the INFO police; quite the opposite. I think we make it easier to do
vendor proprietary stuff (within a vendor namespace), and we can
define the extension procedure such that the bar is loweFrom sip-bounces at ietf.org Wed Jul 23 09:47:55 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 3DEBC3A69A7;
Wed, 23 Jul 2008 09:47:55 -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 F0DD03A69D4
for <sip at core3.amsl.com>; Wed, 23 Jul 2008 09:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.656
X-Spam-Level:
X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5
tests=[AWL=-0.057, 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 r4qBEiej-kXZ for <sip at core3.amsl.com>;
Wed, 23 Jul 2008 09:47:52 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com
[66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 12BA13A69A7
for <sip at ietf.org>; Wed, 23 Jul 2008 09:47:52 -0700 (PDT)
Received: from [75.68.119.237] (port=63121 helo=[192.168.15.101])
by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128)
(Exim 4.68) (envelope-from <eburger at standardstrack.com>)
id 1KLhVo-0003PK-7c; Wed, 23 Jul 2008 09:48:24 -0700
Message-Id: <B9F3F289-3B3A-49B6-B0C4-1728DD1751A0 at standardstrack.com>
From: Eric Burger <eburger at standardstrack.com>
To: Jonathan Rosenberg <jdrosen at cisco.com>, Paul Kyzivat <pkyzivat at cisco.com>,
Dean Willis <dean.willis at softarmor.com>
In-Reply-To: <487D6CA8.9030103 at cisco.com>
Mime-Version: 1.0 (Apple Message framework v926)
Date: Wed, 23 Jul 2008 12:48:24 -0400
References: <487CEA48.6090605 at softarmor.com>
<487CF5DF.6010709 at cisco.com> <9F5F5B8C-52A9-46A4-897D-0098AE9A0C9E at softarmor.com>
<487D4058.5020700 at cisco.com> <487D6CA8.9030103 at cisco.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
Must be different registries for all the reasons JDR & Paul mention.
I am torn on the Proprietary Registry, however. We *think* we know
all the bizarre ways people use INFO in the world, but I am constantly
surprised by some of the "unique" things that get discussed on the SIP
Forum Discussion list. On the one hand, we would want to have an open
call for proprietary implementations so we can register and analyze
them. On the other hand, one could see how that could encourage new,
yet obsolete, INFO usages.
Given that at least two of the extant INFO I-D's enumerate the classes
of INFO usage in the wild, is there ANY value to a Proprietary INFO
Registry?
On Jul 15, 2008, at 11:36 PM, Jonathan Rosenberg wrote:
I agree with Paul; these need to be different registries.
I also agree that inventing a new info framework will NOT make us
the INFO police; quite the opposite. I think we make it easier to do
vendor proprietary stuff (within a vendor namespace), and we can
define the extension procedure such that the bar is lowered for red for
things that folks want cross-vendor interop but don't want to go
through the whole ietf process.
Frankly, I think the framework defined in Hadriels' draft is pretty
barebones minimum - its basically a couple of headers which define
what you support.
I do NOT want to use the existing option tags mechanism for this -
or Require/Supported - it then requires standards track for these
and we don't want that.
-Jonathan R.
Paul Kyzivat wrote:
Dean,
It does no good to retroactively invent new info usages for the
existing usages of INFO, because the implementations don't know
about them. They figure out that it is *their* usage from context,
which in practice ends up being content-type. (I suppose its
*possible* that somebody overloads a c-t and discriminates on some
other basis, but I strongly doubt it.)
But the new ones are going to discriminate on info-type, not
content-type. At least I think so.
The only way you can force them all into the same namespace is by
making all the new ones discriminate based on c-t.
Having two namespaces/registries does not require the sip wg to
stay around as police. All we need to do is define the admission
rules. A simple rule would be:
- the usage had to exist before date D1
- it must be added to the registry before date D2
- FCFS per C-T
Then on D2 that registry is permanently closed. That means that
anybody with an existing usage needs to hurry to get it registered.
Or, we can forget about D2, and leave the registry open forever on
a FCFS basis per C-T, with a proviso that only usages that were in
existence prior to D1 are eligible. (But with no enforcement
mechanism for that.)
Now that I think about it, maybe it can't even be FCFS per C-T. If
it turns out that more than one usage uses the same C-T, then they
can't interoperate, but presumably they still exist. I guess we
would need to register them and note the conflict, as a warning to
users. Hopefully this won't happen in practice.
Paul
Dean Willis wrote:
On Jul 15, 2008, at 2:09 PM, Paul Kyzivat wrote:
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 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".
Its probably a little different from either of these existing
policies.
Thats because it should only be applicable to *preexisting* usages.
We don't want new, yet to be deployed, usages registered in this
way.
(We will probably have to use the honor system for determining
which usages qualify.)
I'm proposing that new, yet-to-be-deployed INFO usages would be in
the same registry. Only if they need a SIP Option Tag for
negotiation would they need a standards-track RFC.
I do NOT want the SIP working group to live forever as the "INFO
police". It just really doesn't matter that much what people put
in an INFO as long as they don't hurt each other with conflicting
usages.
things that folks want cross-vendor interop but don't want to go
through the whole ietf process.
Frankly, I think the framework defined in Hadriels' draft is pretty
barebones minimum - its basically a couple of headers which define
what you support.
I do NOT want to use the existing option tags mechanism for this -
or Require/Supported - it then requires standards track for these
and we don't want that.
-Jonathan R.
Paul Kyzivat wrote:
Dean,
It does no good to retroactively invent new info usages for the
existing usages of INFO, because the implementations don't know
about them. They figure out that it is *their* usage from context,
which in practice ends up being content-type. (I suppose its
*possible* that somebody overloads a c-t and discriminates on some
other basis, but I strongly doubt it.)
But the new ones are going to discriminate on info-type, not
content-type. At least I think so.
The only way you can force them all into the same namespace is by
making all the new ones discriminate based on c-t.
Having two namespaces/registries does not require the sip wg to
stay around as police. All we need to do is define the admission
rules. A simple rule would be:
- the usage had to exist before date D1
- it must be added to the registry before date D2
- FCFS per C-T
Then on D2 that registry is permanently closed. That means that
anybody with an existing usage needs to hurry to get it registered.
Or, we can forget about D2, and leave the registry open forever on
a FCFS basis per C-T, with a proviso that only usages that were in
existence prior to D1 are eligible. (But with no enforcement
mechanism for that.)
Now that I think about it, maybe it can't even be FCFS per C-T. If
it turns out that more than one usage uses the same C-T, then they
can't interoperate, but presumably they still exist. I guess we
would need to register them and note the conflict, as a warning to
users. Hopefully this won't happen in practice.
Paul
Dean Willis wrote:
On Jul 15, 2008, at 2:09 PM, Paul Kyzivat wrote:
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 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".
Its probably a little different from either of these existing
policies.
Thats because it should only be applicable to *preexisting* usages.
We don't want new, yet to be deployed, usages registered in this
way.
(We will probably have to use the honor system for determining
which usages qualify.)
I'm proposing that new, yet-to-be-deployed INFO usages would be in
the same registry. Only if they need a SIP Option Tag for
negotiation would they need a standards-track RFC.
I do NOT want the SIP working group to live forever as the "INFO
police". It just really doesn't matter that much what people put
in an INFO as long as they don't hurt each other with conflicting
usages.
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.
I think either this is a different registry, or else it is the
same registry but a different class of entry.
Nope.
I'm inclined to think it is a different registry because it is a
different namespace. The namespace for (1) is mime-types, while
for (2) it is a unique namespace of Info-types.
That's not what I'm suggesting; it's NOT mime-types; it's Info-
types in all cases. I'm saying we retroactively invent an Info-
type for each documented existing usage. As people rev their old-
use code, they would add the Info-type to their Info messages.
It might be OKAY to have a mime-type as an additional column in
the registry, although that potentially leads us down an area of
mime-type exclusion.
Do we also need a set of content-dispositions for each Info-type?
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.
Revising the old usages is IMO counterproductive. They are what
they are.
ok.
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).
Its not even that bad. It only whacks the dialog if you put
Requires in the dialog-establishing request. If you simply put it
in the INFO itself, then the dialog doesn't get whacked.
Let's say that you send a 4XX error response to an in-dialog INFO
(because you don't understand the Info-type of the dialog). What
does that do to the dialog?
--
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
--
Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
Cisco Fellow Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen at cisco.com
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
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
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.
I think either this is a different registry, or else it is the
same registry but a different class of entry.
Nope.
I'm inclined to think it is a different registry because it is a
different namespace. The namespace for (1) is mime-types, while
for (2) it is a unique namespace of Info-types.
That's not what I'm suggesting; it's NOT mime-types; it's Info-
types in all cases. I'm saying we retroactively invent an Info-
type for each documented existing usage. As people rev their old-
use code, they would add the Info-type to their Info messages.
It might be OKAY to have a mime-type as an additional column in
the registry, although that potentially leads us down an area of
mime-type exclusion.
Do we also need a set of content-dispositions for each Info-type?
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.
Revising the old usages is IMO counterproductive. They are what
they are.
ok.
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).
Its not even that bad. It only whacks the dialog if you put
Requires in the dialog-establishing request. If you simply put it
in the INFO itself, then the dialog doesn't get whacked.
Let's say that you send a 4XX error response to an in-dialog INFO
(because you don't understand the Info-type of the dialog). What
does that do to the dialog?
--
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
--
Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
Cisco Fellow Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen at cisco.com
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
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