Subject: [Sipping] Re: draft-rosenberg-sipping-app-interaction-framework-00

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Nov 2002 16:10:07 -0500

There has been a lot of great work going on!

I have a few small points about this framework.

	Paul

1) Look at the difference between the following:

        REQ 3: An application must be able to add ...
                  ^^^^^^^^^^^
             a user interface component into any
             request or response that passes through or is eminated from
             that application.

        REQ 4: A UA application must be able to send a SIP message to
                 ^^^^^^^^^^^^^^
             the UA at the other end of the dialog, asking it to create
             a new interface component.

Why is it that any application (including an intermediary) is permitted to add a UI component to a message that happens to be going by, but only a UA application can add one when a message doesn't happen to be going by?

Of course the simple answer is that an intermediary isn't permitted to originate a suitable message to accomplish this. But that is only a reason why it can't be done, not a reason why it isn't a requirement. I can see no reason why an intermediary has less need for this than a UA. If it were made a requirement, then perhaps a way could be found to achieve it.

---

2) Tying interface components to dialogs:

   User interface components have a well defined lifetime. They are
   created when the component is first pushed to the client. User
   interface components are always associated with the SIP dialog on
   which they were pushed. As such, their lifetime is bound by the
   lifetime of the dialog. When the dialog ends, so does the interface
   component.

Is this really true, or is it associated with a use of a dialog, like an INVITE session?

Specifically, if there are two users of a dialog - say an INVITE session and a subscription, then if the call ends with a BYE, the dialog will remain until the subscription ends. Does a UI component established as a result of the INVITE message remain in this case?

Maybe all this UI stuff should be explicitly tied to "call" rather than "dialog".

----

3) Nit: Somehow I don't think the following says what was intended. :-)

   The separation between user interface and application is absolutely
   fundamental to the entire framework provided in this document. Its
   importance cannot be understated.
                        ^^^^^
                        ?????
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Eric Cheung <[email-masked]>
Date: Wed, 06 Nov 2002 13:02:31 -0500

Hi Jonathan

You guys put in a great deal of work into this set of I-Ds.  Good work!

A really small nit that need to picked nonetheless to help me
understand.  In section 7.2.3 Comparison, it seems the pipe-and-filter
model and the client resolution model are both referred to as "Section
7.2.2"?  For example, the first sentence in second paragraph "The model
in Section 7.2.2 has many benefits." I think you mean 7.2.2.1?

Perhaps it might be better to number these sections 7.2.2, 7.2.3 and
7.2.4.

Thanks
Eric