[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Legacy Info Package Registration
[X] Punt - I may or may not want an IANA registry, but if we do create
one, do it in another draft
I think we should punt for now. However, IF we decide that for SIP, as a
whole, we do try to bring more real implemenation stuff into the fold,
then I think we should have a registry, that should be included in a
separate document. I'm afraid we may get very delayed if we try to do
that now, as there may be a tendency to analyze legacy usages in terms
of how reasonable people think they are - i.e., there may be some for
which there is a clear standard's solution and then we'll debate whether
we include them all whether folks would ever deem them useful or not.
Mary.
-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
Eric Burger
Sent: Thursday, October 30, 2008 11:14 AM
To: Paul Kyzivat
Cc: SIP IETF
Subject: [Sip] Legacy Info Package Registration
We discussed creating a registry, and we discussed whether it would be
in this document.
On the one hand, the discussion was not conclusive. On the other, here
are my reasons for not including it in the Info Packages document:
1. We go at lengths to say how to do Info Packages. The last thing we
need to do is say, "by the way, it's not so bad if you don't."
2. People not involved today will look at such a registry and, no matter
how much doom and gloom wording we use, will From sip-bounces at ietf.org Thu Oct 30 13:09:01 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 8B7FA3A68BF;
Thu, 30 Oct 2008 13:09:01 -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 981EE3A68BF
for <sip at core3.amsl.com>; Thu, 30 Oct 2008 13:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.31
X-Spam-Level:
X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[AWL=0.289,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 9gSxQAoPDP4c for <sip at core3.amsl.com>;
Thu, 30 Oct 2008 13:08:59 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56])
by core3.amsl.com (Postfix) with ESMTP id 7804D3A6894
for <sip at ietf.org>; Thu, 30 Oct 2008 13:08:59 -0700 (PDT)
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com
[47.103.123.72])
by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
m9UK8pV00902; Thu, 30 Oct 2008 20:08:51 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 30 Oct 2008 15:05:25 -0500
Message-ID: <F66D7286825402429571678A16C2F5EE060E08C4 at zrc2hxm1.corp.nortel.com>
In-Reply-To: <81521DF0-2666-4500-BE62-412FBB6966A7 at standardstrack.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Legacy Info Package Registration
Thread-Index: Ack6tdhvcdy6u0IiRLWq8BLS2MC73AAFDHNA
References: <20081020231502.43DCA3A69EF at core3.amsl.com>
<48FDECB5.3030607 at cisco.com>
<81521DF0-2666-4500-BE62-412FBB6966A7 at standardstrack.com>
From: "Mary Barnes" <mary.barnes at nortel.com>
To: "Eric Burger" <eburger at standardstrack.com>
Cc: SIP IETF <sip at ietf.org>
Subject: Re: [Sip] Legacy Info Package Registration
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
[X] Punt - I may or may not want an IANA registry, but if we do create
one, do it in another draft
I think we should punt for now. However, IF we decide that for SIP, as a
whole, we do try to bring more real implemenation stuff into the fold,
then I think we should have a registry, that should be included in a
separate document. I'm afraid we may get very delayed if we try to do
that now, as there may be a tendency to analyze legacy usages in terms
of how reasonable people think they are - i.e., there may be some for
which there is a clear standard's solution and then we'll debate whether
we include them all whether folks would ever deem them useful or not.
Mary.
-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
Eric Burger
Sent: Thursday, October 30, 2008 11:14 AM
To: Paul Kyzivat
Cc: SIP IETF
Subject: [Sip] Legacy Info Package Registration
We discussed creating a registry, and we discussed whether it would be
in this document.
On the one hand, the discussion was not conclusive. On the other, here
are my reasons for not including it in the Info Packages document:
1. We go at lengths to say how to do Info Packages. The last thing we
need to do is say, "by the way, it's not so bad if you don't."
2. People not involved today will look at such a registry and, no matter
how much doom and gloom wording we use, will think itthink it's OK to not use
Info Packages.
3. People will be confused, thinking Content-Type is sufficient to
identify an Info Package. It is not.
4. How would we possibly police the registry? If someone comes to IANA
to register a new MIME type do the klaxons ring? That would not be a
good thing.
So, time for another poll:
[ ] Yes - we really, really need an IANA registry of "legacy" INFO
usages, and we need it done in this draft
(NOTE: creating the IANA registry requires the seed values, which
means this draft will enumerate the
known legacy usages)
[ ] No, do not create an IANA registry, but please enumerate known
legacy usages in this draft
[ ] No - please do not create an IANA registry
[ ] Punt - I may or may not want an IANA registry, but if we do create
one, do it in another draft
[ ] Other: ________________________________
On Oct 21, 2008, at 10:52 AM, Paul Kyzivat wrote:
> Regarding registration if INFO packages - I thought we also wanted to
> introduce a registry for legacy usages of INFO, to encourage them to
> come out into the daylight. I guess maybe that would be a separate
> registry, since the key for it will have to be Content- Type. So it
> *could* be established from a different document. But I think this is
> the likely place to do it, since its the place where all the eyeballs
> will be. I think the rule for registering those needs to be that one
> can only be registered if the Content-Type has not already been
> registered, and it was in *use* with INFO prior to this document
> becoming an RFC. (The registration itself could be done later. I guess
> it would be the honor system.) Any usages being deployed after this
> becomes an RFC would be required to use the new mechanism.
_______________________________________________
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
's OK to not use
Info Packages.
3. People will be confused, thinking Content-Type is sufficient to
identify an Info Package. It is not.
4. How would we possibly police the registry? If someone comes to IANA
to register a new MIME type do the klaxons ring? That would not be a
good thing.
So, time for another poll:
[ ] Yes - we really, really need an IANA registry of "legacy" INFO
usages, and we need it done in this draft
(NOTE: creating the IANA registry requires the seed values, which
means this draft will enumerate the
known legacy usages)
[ ] No, do not create an IANA registry, but please enumerate known
legacy usages in this draft
[ ] No - please do not create an IANA registry
[ ] Punt - I may or may not want an IANA registry, but if we do create
one, do it in another draft
[ ] Other: ________________________________
On Oct 21, 2008, at 10:52 AM, Paul Kyzivat wrote:
> Regarding registration if INFO packages - I thought we also wanted to
> introduce a registry for legacy usages of INFO, to encourage them to
> come out into the daylight. I guess maybe that would be a separate
> registry, since the key for it will have to be Content- Type. So it
> *could* be established from a different document. But I think this is
> the likely place to do it, since its the place where all the eyeballs
> will be. I think the rule for registering those needs to be that one
> can only be registered if the Content-Type has not already been
> registered, and it was in *use* with INFO prior to this document
> becoming an RFC. (The registration itself could be done later. I guess
> it would be the honor system.) Any usages being deployed after this
> becomes an RFC would be required to use the new mechanism.
_______________________________________________
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