Brian Stucker wrote:
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: Friday, October 12, 2007 12:57 PM
To: Stucker, Brian (RICH1:AR00)
Cc: Dean Willis; DRAGE, Keith (Keith); IETF SIP List; Audet,
Francois (SC100:3055); Christer Holmberg
Subject: Re: What are we arguing about when we say INFO? (was
Re: [Sip] INFO)
Brian Stucker wrote:
You forgot about supported.
So for example, DTMF: Using this model of SIP extension, we might
define a new "DTMF" method. It would look just like
DTMF-over-INFO,
except the name of the method would be DTMF.
It clearly resolves the INFO-context question, because now we KNOW
we're getting dialog- related DTMF over it, and we know what to do
with it. We know what we can transport in DTMF-requests,
because the
RFC that defines the DTMF extension method will also
define exactly
what payload format to use.
INVITE
Supported: foo
Allow: INFO
Accept: application/foo
200 OK
Supported: foo
Allow: INFO
Accept: application/foo
...
INFO
Content-Type: application/foo
[DTMF]
Where is this broken?
This can work if there is an RFC defining the foo option that
specifies that when both parties support foo then:
- the UAC may use INFO to send information using
Content-Type application/foo and Content-Disposition: (TBD)
- the circumstances triggering the UAC to send are ...
- the expected actions of the UAS upon receiving are ...
Because this uses an option, and a new option can only be
defined via an RFC, this technique is only available
(legally) when an RFC will be approved. (Of course people
have been known to invent new options without an RFC, but
that is non-conforming usage.)
That seems like more of a legal loophole for defining event header
values than anything else.
Event types and sip option tags are separate namespaces with different
registration ruies:
- event types: Informational RFC approved by the IESG
- option tags: Publication of standards track (section 27.1)
So the bar is slightly lower for event types.
There's only one currently IANA registered
event header value that is not associated with an RFC and I doubt that
one is going to live for very long in light of RTCP-XR.
Are you advocating not having to have an RFC for an event header as a
positive thing? If so, then isn't this equivalent to a vote for leaving
INFO alone?
No, I'm not advocating it as a good thing. I am acknowledging that
people will do it for proprietary reasons, but that if they later come
forward and try to get the usage formally approved then there is a bar
to get over.
You can publish a informational rfc for your proprietary event type
without any consensus of the wg, etc. But getting a standards track rfc
approved for an option tag will require the wg to bless your approach.
Paul
Regards,
Brian
_______________________________________________
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
