Jesske, R wrote:
Because RFC 2976 is wrong, and we are willing to correct our mistakes.
So lets start. But I'm not willing to restrict INFO to ISUP & QSIG MIME only.
There are a variety of things we could do, together or separately:
1)revise 2976 to restrict INFO to standardized usages. Make any other
usage MUST NOT.
2)establish an IANA registry for uses of INFO based on Content-Type.
It would define what information is needed to define a usage.
Initially populate it with the existing standardized usages.
The criteria for adding new uses could be:
a) Stds track RFC
b) Informational RFC
c) FCFS
3)establish a policy that the WG won't approve any other usages of INFO,
beyond the existing ISUP/QSIG ones. (Then we don't need a registry.)
4)do nothing - status quo. Existing uses
IMO anything that bans the current practices (i.e. (1)) that haven't
been standardized is futile - it won't cause them to stop. IMO we seem
to have a significant majority in favor of (3), though apparently not a
consensus.
So I think the realistic possibilities are (2) or (4). And (2a) is
pretty much the same as (1) so it isn't realistic either.
One of the other variants of (2) could reflect the realities and improve
on the current situation in that at least the existing usages would be
documented in public.
Paul
BR
Roland
-----Ursprüngliche Nachricht-----
Von: Eric Burger [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 18. Juni 2007 19:23
An: Jesske, Roland; [email protected]
Betreff: Re: AW: [Sip] INFO usage (or not)
Because RFC 2976 is wrong, and we are willing to correct our
mistakes. Good news is that other than 3204, there are no
documented standards track uses of INFO. There is one
informational RFC that talks about its use in the wild (for
media server control), but if you look at it (RFC 4722) you
will see the #1 reason for using info was that in the day,
there was no other alternative.
Given NO IETF standards use INFO, and we have been explaining
why it is a bad idea for close to five years now, I do not
see the problem with setting the record straight.
--
Sent from my wireless e-mail device. Sorry if terse. We all
need lemonade: see
<http://www.standardstrack.com/ietf/lemonade> for what lemonade is.
-----Original Message-----
From: Jesske, R <[EMAIL PROTECTED]>
To: Eric Burger; [EMAIL PROTECTED]
<[EMAIL PROTECTED]>; [email protected] <[email protected]>
Sent: Mon Jun 18 02:01:29 2007
Subject: AW: [Sip] INFO usage (or not)
Hi,
Why should be RFC's that are now 6 Years out in the world be
restricted?
RFC 2976 clearly states for what INFO can be used.
I'm concerned about implementations that works with INFO
regarding the rules defined within 2976.
Many implementations work based on that RFC. Like define a
MIME, put it into INFO and it works.
I thought also that INFO was defined to put in some end to
end information that shall be exchanged by UA's.
Why to restrict such a use in such a case?
If RFC 2976 will be changed is backward compatibility guaranteed?
Best Regards
Roland
-----Ursprüngliche Nachricht-----
Von: Eric Burger [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 17. Juni 2007 11:53
An: Keith Drage; IETF SIP List
Betreff: Re: [Sip] INFO usage (or not)
How about this:
This document describes why the Session Initiation Protocol
(SIP) INFO
method, introduced in RFC 2976, has serious issues with any
use outside its
use as a transport mechanism for ISDN User Part (ISUP) call
signaling in
SIP-signaled networks. In the years since the introduction
of the INFO
method, the IETF has published numerous, interoperable
extensions to SIP.
This document explains why there are INFO-based, proprietary
protocols in
the wild; the flaws of using INFO; and prescriptions for how to use
existing, interoperable SIP mechanisms to accomplish most
any of these
tasks.
My personal preference is for the document to be Standards
Track and be a
Work Group chartered item. The reason is that for this
document to be
useful, it MUST update RFC 2976. If it updates RFC 2976,
then newbies get
the pointer when the download RFC 2976, pointing them to this
document,
before they go off, create draft-mumble-foo-over-INFO, and
get flamed on the
list. The essence of the normative content of the document
is, "one MUST
NOT use INFO for anything other than transporting ISUP or
QSIG messages."
Because the normative content is so thin, I could understand
not saying that
and making the document Informational (or BCP). However, I
really and truly
believe that will significantly reduce the impact the
document will have.
Outline:
Introduction
- Requirements for UA-to-UA signaling
- The INFO method
- The INFO method for ISUP signaling
Issues with INFO
- No or incomplete negotiation
- No real identification of payload purpose on receipt
Alternatives to INFO
- State Updates: SUBSCRIBE / NOTIFY
- DTMF Transport: KPML (an example of state updates)
- Establishment of direct UA-to-UA signaling channel: MRCPv2, MSRP
- Prescriptions for deciding which method is appropriate under what
circumstances
Update to RFC 2976
- Limiting use of INFO to ISUP transport only
Security Considerations
On 6/13/07 9:28 AM, "DRAGE, Keith (Keith)"
<[EMAIL PROTECTED]> wrote:
(As WG chair)
We have got a number of threads floating round on INFO
usage, and it
would be nice to identify this into a potential body of
work, and see if
there is support for it.
We have two previous drafts that never went anywhere,
although contents
of both carried support in the WG at the time:
http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00
The Session Initiation Protocol (SIP) INFO method
defines a means for
transporting mid-dialog application layer data between
user agents.
Its initial use was to support the transport of ISUP mid-call
messages which could not be mapped to any other SIP
request method.
However, since its initial usage for that purpose,
INFO has seen
widespread abuse as a means for introducing non-standard and
non-interoperable extensions to SIP. For this reason,
we now believe
INFO should be considered harmful, and therefore,
deprecated in its
current form.
http://tools.ietf.org/html/draft-willis-sip-infopackage-00
The SIP INFO method (RFC 2976) establishes a method by which
applications may transfer application-specific
information within a
SIP dialog. However, RFC 2976 does not provide a mechanism for
describing and documenting an application of INFO, nor does it
provide a mechanism by which applications may negotiate
such uses.
This document provides a framework for documenting and naming
specific uses of INFO (called INFO packages), for
registering those
package names with IANA, and for negotiating the support
for various
INFO packages between applications using SIP.
In the thread so far there have also been suggestions that cover:
- support to mediactrl for their discussion on requirements
- something for hitchhiker's guide to point to:
- something that answers all the questions that recur on this list
on INFO usage
- "I've been getting a lot of offline questions asking for the
"right" way to carry information related to the
session-usage (often
information that's being tunneled around from companion
or gatewayed
protocols)."
- INVITE dialog usage only, or already covered by RFC 2976
- It would be OK with me if we ALSO had this type of guidance
("don't look HERE, look over THERE") available ("stated
strongly enough
in an easy to stumble across place"), but if coming up with that
guidance takes more than about a week, I don't see a lot of
reason to
hold up on "don't go there"
while we explore alternatives.
- INFO and DTMF
- XML payloads
- But people really need is guidance on when to use INFO, when to
use events, and when to use something entirely different.
- identification of purpose of info (Content-Type? - impacted by
multipart/mixed)
- any framework for control of usages (IANA registration? - RFC
3427 update)
Would anybody out there like to have a go at drafting an
abstract for a
potential WG deliverable (and also identifying level - Info, BCP,
standards track) and submitting it to the list for
discussion. Remember
an abstract needs to:
--------------------------------------------------------------
----------
-------
Every RFC must have an Abstract section following the
Copyright notice.
An Abstract will typically be 5-10 lines. An Abstract of
more than 20
lines is generally not acceptable.
The Abstract section should provide a concise and
comprehensive overview
of the purpose and contents of the entire document, to give a
technically knowledgeable reader a general overview of the
function of
the document. In addition to its function in the RFC itself, the
Abstract section text will appear in publication
announcements and in
the online index of RFCs.
Composing a useful Abstract generally requires thought and
care. Usually
an Abstract should begin with a phrase like "This memo
..." or "This
document ...". A satisfactory abstract can often be
constructed in part
from material within the Introduction section, but a good
abstract will
be shorter, less detailed, and perhaps broader in scope than the
Introduction. Simply copying and pasting the first few
paragraphs of the
Introduction is tempting, but it may result in an Abstract
that is both
incomplete and redundant. Note also that an Abstract is not
a substitute
for an Introduction; the RFC should be self-contained as if
there were
no Abstract section.
An Abstract should be complete in itself; it should not contain
citations unless they are completely defined within the Abstract.
Abbreviations appearing in the Abstract should generally be
expanded in
parentheses. There is a small set of reasonable exceptions
to this rule
(see guidelines on abbreviations, above.)
--------------------------------------------------------------
----------
------
And as such should give a clear idea of whether there is
anything we
should charter here or not.
Regards
Keith
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the
application of sip
Notice: This email message, together with any attachments,
may contain information of BEA Systems, Inc., its
subsidiaries and affiliated entities, that may be
confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the
individual or entity named in this message. If you are not
the intended recipient, and have received this message in
error, please immediately return this by email and then delete it.
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
Notice: This email message, together with any attachments,
may contain information of BEA Systems, Inc., its
subsidiaries and affiliated entities, that may be
confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the
individual or entity named in this message. If you are not
the intended recipient, and have received this message in
error, please immediately return this by email and then delete it.
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
