[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sipping] Thoughts on the conf-info package
Answers are below.
BR,
Orit .
-----Original Message-----
From: David R. Oran [mailto:oran@cisco.com]
Sent: Thursday, May 23, 2002 11:35 AM
To: sipping@ietf.org
Subject: RE: [Sipping] Thoughts on the conf-info package
--On Thursday, May 23, 2002 11:20 AM -0400 Orit Levin <orit@radvision.com>
wrote:
> Hi guys!
> I think that Rohan's "thoughts about conferencing" hit a number of crucial
> missing points.
> Before arguing about the implementation, I will try to summarize the
> implicitly disputed requirements:
>
> 1. When a user is invited to a session, which is a part of a conference,
> information MUST be provided to the user informing him that he is a part
> of the conference. (The user MAY ignore this information.)
Excuse me, but I must be naive. Why is this a MUST? How is this any
different from multiple people in the same room sharing an instrument? I'm
not saying the information isnot useful, but I see no reason why it MUST be
providedin all circumstances.
OL: My phrasing was a mistake. I meant: "standard SIP means for providing
information MUST be defined". Use of these means is a local policy.
> 2. When a point-to-point session is expanded to a conference, information
> MUST be provided to the user informing him that he becomes a part of the
> conference. (The user MAY ignore this information.)
>
Again, why? I don't get this information when my wife picks up an extension
line.
OL: Same correction as above.
> I see two separate cases for these requirements (which makes them 4
> requirements):
> 1. If the requirements are for the human "user", then the provided
> conferencing information is mostly for "display" and I don't see reason
> for standardizing the syntax and the semantics of the information.
Huh? Then how do I know how to render it?
> Of
> cause, we need to standardize where we convey this information. This
> would be a general approach: not for Conferencing only.
I'm not following this part.
OL: The information itself contains its reason: "You are in a Conference
now" or "Your call has been forwarded".
> 2. If the requirements are for the "User Agent", then the encoding and the
> syntax of the conferencing indication MUST be standardized.
I find your distinction unuseful. The only thing relevant to our work is
the UA - the user is wetware and is clearly outside the scope of our work.
:-)
> This is useful
> for "smart" User Agents that are capable of automatic participation in a
> Conference (on behalf of the human user) such as activating additional
> user interface, displaying conferencing information, and much more (for
> example, by automatic activation of UA's Conferencing module). In this
> case the provided information MUST include standard Identification of
> this Conference (BTW another open requirement).
>
Why? Again I'm not arguing tha the informaiton isnot useful, only that the
system is not broken if it isn't available, and hence "MUST" is way too
strong a requirement.
OL: Do you mean that if the ID isn't provided, the operations are limited to
the in-band SIP session means? I don't disagree with you if we agree on the
intention. On the other hand, if the ID is provided it MUST be standard.
> I can definitely see place for both sets of requirements. Although, from
> the first sight, it seems that the second case includes the first, they
> can be addressed separately for the sake of really simple (i.e.
> conferencing unaware) User Agents.
>
> Which are we trying to address?
UA's only. Without neruonal interfaces and quantum cognition sensors there
is no way we can address directly the requirements of human users. :-)
OL: Thanks for the vote :)
> Which would we like to address?
> (I vote for all 4 addressed separately.)
>
> Additional points of view?
> Orit .
>
> -----Original Message-----
> From: Anders Kristensen [mailto:akristensen@dynamicsoft.com]
> Sent: Wednesday, May 22, 2002 7:07 PM
> To: Rohan Mahy
> Cc: sipping@ietf.org
> Subject: Re: [Sipping] Thoughts on the conf-info package
>
>
>
> Rohan Mahy wrote:
>>
>> On Wed, 22 May 2002, Anders Kristensen wrote:
>>
>>>>> I think it is simpler. It doesn't require UAs to understand REFER and
>>>>> Call-Info and this particular use of both. It seems a bit odd to me
>>>>> that the exact same information goes into two very different headers,
>>>>> Refer-To and Call-Info, depending on how the receiver gets to join the
>>>>> conference.
>>>>
>>>>
>>>> (aside: to be good SIP citizens I think UAs will need to support REFER
>>>> anyway.)
>>>>
>>>> Specifically, "the exact same information" you are talking about is a
>>>> SIP URI which specifies a request-URI, the SUBSCRIBE method, and a
>>>> specific event package. The semantics are clear regardless how you
>>>> discovered this URI. This URI could have been embedded in a web page
>>>> and the semantics are still the same. It should be apparent to anyone
>>>> that you can put a URI in a Refer-To header, a Call-Info header, a
>>>> Contact
> header,
>>>> the Request-URI, etc. I understand that it takes a little getting used
>>>> to and might seem odd at first, but this is all very natural SIP
> behavior.
>>>
>>> So you're basically saying it doesn't matter which header this URI is
>>> carried in. You can put SIP URIs many different places, yes, but it
>>> usually means something different. Two different headers being used to
>>> the same effect is BAD.
>>
>>
>> You are confusing the sematics of the mechanism you use to get some
>> information, with the semantics of the information itself. By analogy,
>> you can send me the same content by email or via an instant message. The
>> semantics of the information is the same, but the semantics of the
>> two mechanisms are very different.
>
> I absolutely disagree. Well-defined SIP headers should imply semantics.
> They're not for general purpose transport of random information which
> you feel is somehow self identifying in terms of meaning.
>
> I'll go a step further and suggest that any header that lends itself to
> that sort of hijacking may be too vaguely defined.
>
> Anders
>
>
> _______________________________________________
> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
>
> _______________________________________________
> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
-----------------------------------------------------------
David R. Oran Phone/Fax: +1 978 264 2048
Cisco Systems VoIP: +1 408 571 4576
7 Ladyslipper Lane Email: oran@cisco.com
Acton, MA 01720
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP