> -----Original Message-----
> From: Eric Burger [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 10, 2007 8:08 AM
> To: Stucker, Brian (RICH1:AR00)
> Cc: [email protected]
> Subject: Re: [Sip] INFO
>
> Brian Stucker Says:
> I'm not really sure what your point was
> here unless you are against people
> writing down a common way of using
> a protocol amongst themselves
>
> Actually, I have no problem with "people writing down a
> common way of using a protocol". One would offer that is the
> work of the IETF. However, the key phrase I have a problem
> with is, "amongst themselves." The IETF makes protocols for
> everybody, not just members of the garden club. The garden
> club can do whatever they want inside their garden. The IETF
> has no right nor interest in mandating what goes on inside
> their garden.
True, but it's not a club. Those disclaimers are to limit reproduction
of the material by other SDOs without permission. You don't have to be a
member of the garden club to use the protocols written by the garden
club, such as they are. Whether you want to or not is another matter
entirely.
[SNIP]
> In my mind, INFO for DTMF falls into the, "it is not an
> Internet protocol, but you can do whatever you want in your
> playground, so long as your fences are good and you will
> still play with me. P.S., do not claim you are using Internet
> protocols, because you are not."
Only because they happen to not be written down as an IETF document,
which, as I suggested earlier, may be the solution to the problem.
>
> P-Preferred-Service is an example of something that falls
> into "the toxic substance that will bleed through, so do not
> even think of using it" category.
So then I would be most interested to hear your thoughts on the
following:
The first sentence in section 2 in your draft states:
"There is no programmatic way of determining what the content of
an INFO request means."
You could say the same is true for an INVITE. To the 'User-Agent's point
of view, an [INVITE] just appears'. Without a negotiation mechanism such
as SDP, is this INVITE conveying an conference call, a user-to-user
gaming session, or what? We can't programmatically determine what an
INVITE with no SDP means. So if I'm following your argument here wrt
INFO, the analogous solution would be to deprecate INVITE unless it
always has SDP.
But wait, there's more... Again, using your line of thought for INFO,
SDP may not be good enough:
"However, as we learned in the messaging community [7], relying
upon the MIME type alone is not sufficient to determine the context of
the message. Clearly, as shown in the previous paragraph [which
describes using the MIME type of an INFO as a negotiation mechanism],
the message content relates to the message context. However, it is quite
easy to imagine situations where the same content type has multiple
meanings for a User Agent."
So if the content relates to the message context, and the content and
type can be ambiguous, such as the INVITE contains SDP, or the SDP
contains an audio stream (is it a conference or is it a podcast or what)
or worse, SDP that contains content types that are not well-known, then
clearly SIP and SDP are not enough to correctly identify what the User
Agent is to do with this request. Hence, a mechanism such as
P-Preferred-Service rears it's ugly head.
As a result, if I understand you correctly, rather than correct the
negotiation problem (more like just write it down because it's already
being neogitated out there in the wild in many cases) and let the UAs
deal with it, you'd rather deprecate the whole thing in favor of
something else. Correct?
Also, your list of examples is missing one usecase that KPML definitely
does not address (but session timers does): INFO is used to detect if a
call is still alive.
Cheers,
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
