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

Jonathan,

I have a couple of comments about this version, below.

	Paul

Section 5.2:

    To authenticate themselves, it is RECOMMENDED that applications use
    the SIP identity mechanism [11] in the REFER or SUBSCRIBE requests
    they generate. A UA will need to authorize these subscriptions and
    refers. To do this, a UA SHOULD accept any REFER or SUBSCRIBE sent to
    the GRUU it used for that dialog. This would imply that only elements
    privy to the INVITE requests and responses could send a REFER or
    SUBSCRIBE to the UA. The usage of the sips URI scheme provides
    cryptographic assurances that only elements on the call setup path
    could see such information. Therefore, it is RECOMMENDED that UAs
    compliant to this specification use sips whenever possible. A client
    SHOULD use grid parameters with sufficient randomness to eliminate
    the possibility of an attacker guessing the GRUU.

This seems a bit loose. It isn't always going to be practical to use 
sips. (The callee may not support it.) Without it there is danger. What 
is the recommendation in that case?

Section 5.4:

    A client can remove a UI component at any time. For presentation
    aware UI, this is analagous to the user dismissing the web form
    window. There is no mechanism provided for reporting this kind of
    event to the application.

The initial refer created an implicit subscription. It is possible, but 
not required by the event mechanism, for event generation to continue 
for the life of the resulting interface component. If so, a suitable 
event could signal the termination of the interface component.

_______________________________________________
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