Subject: [Sipping] Re: comments on dialog-package

From: Rohan Mahy <[email-masked]>
Date: Tue, 26 Apr 2005 13:01:27 -0700

Hi Nasir,

This document is already approved, but I can address some of these  
issues in author's 48 hours.  see inline.

> To: <sip at ietf.org>
> Subject: [Sip] comments on sipping-dialog-package-06 draft
> From: "Nasir Khan" <nkhan at bea.com>
> Date: Wed, 20 Apr 2005 22:32:13 -0700
>
> Following are some comments on  
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package 
> -06.txt

thanks for the detailed review.

> 1>  Section 4.1
>
>   “state: This attribute indicates whether the document contains the
>       full dialog information, or whether it contains only information
>       on those dialogs which have changed since the previous document
>       (partial). “
>
> From this it looks that the “state” attribute is partial or full  
> depending upon if “some” or “all” dialogs are reported in the NOTIFY.  
> The semantics of partial or full do not convey any information on the  
> completeness of information within a <dialog> element (in context of  
> any filter that subscriber may have set).
> This needs to be clarified in the spec: Should the implementer flush  
> and rewrite the “row” with that dialog ID even when the dialog-info  
> element indicates “partial” (which would imply that information within  
> the <dialog> element is always complete for subsequent NOTIFY’s) or  
> should it do equivalent of SQL update with whatever information is  
> available within the dialog element. (In this latter case is there a  
> need for equivalent of “full” in context of an individual dialog  
> update).

i will add a sentence to clarify that the behavior is more like a sql  
update.

> 2>  Section 4.1.4
>  “4.1.4  Replaces
>
>    The replaces element is used to correlate a new dialog with one it
>    replaced as a result of an invitation with a Replaces header.  This
>    element is present in the replacement dialog only (the newer dialog)
>    and contains attributes with the call-id, local-tag, and remote-tag
>    of the replaced dialog.
>
>    <replaces call-id="hg287s98s89"
>              local-tag="6762h7" remote-tag="09278hsb"/>”
>
> IMHO instead of call-id, local-tag and remote-tag the dialogID is  
> necessary and sufficient information in the replaces element. The  
> Subscriber may not be authorized to get this “replaced” dialog  
> information like call-id etc.based upon some authorization policy. By  
> giving away the dialog information of the replaced dialog the  
> subscriber can gain information it was not privy of originally.  
> However, if the subscriber was getting notifications for the replaced  
> dialog also then it can use the dialogID to correlate. (Besides the  
> subscriber table will most likely be keyed on dialogID. and user.)

while this was probably a good idea, I'm not going to change this since  
the document has already been approved.

> 3>  Section 4.1.5
> “Referred-By [11] header and contains the (optional) display name
>    attribute and the Referred-By URI as its value.
>
>    <referred-by display="Bob">sip:bob at example.com</referred-by>”
>
> There could be identity concerns in sending out the referred-by  
> information. Though not directly concerned with this draft, it could  
> be mentioned about the mechanism to expunge the referer information  
> based on privacy headers. The same applies to other identity elements  
> also.

the notifier can leave out private information, but in practice the  
subscriber to such a dialog is likely to have a very cozy relationship  
with the notifier.

> 4> Section 4.3
> Perhaps it could be added that the dialog information table as  
> suggested is referenced by the SUBSCRIBE/NOTIFY dialog (that which  
> subscriber maintains with the notifier) AND the user whose dialog  
> information is retrieved, this will help to associate the incremental  
> status updates that each NOTIFY entails. In the absence of any such  
> association there could be a problem: Let us say that there were two  
> dialogs that were being reported about, one dialog gets terminated and  
> UA sends a NOTIFY with a higher “version” (+1) attribute. If this  
> NOTIFY is lost and subsequently another NOTIFY with yet higher (+2)  
> version attribute is sent then this SHOULD result in refresh request  
> from Subscriber (sec 4.3). The Notifier will then generate a “full”  
> notification but it will potentially NOT have any information on the  
> “terminated” dialog. The Subscriber now needs a higher level reference  
> to the DialogID that it can use to now flush the now terminated  
> dialog.
> This probably is implied in the text but IMO may help implementers if  
> specified clearly.

I think this is out of scope.  The intent of this package is to insure  
accurate state, not to generate a complete history.  This is similar to  
the presence and message waiting event packages which do not provide  
"historical" state information.

> 5> Should target refreshes be reported, i.e. have a new “event” type  
> in schema for state element <xs:enumeration value="refreshed"/> for  
> target refreshes?

refreshes should be reported, but I don't think a new enumeration is  
necessary.  the subscriber can see that the contact has changed.

> 6> Section 6.1 Minor typo -
> “If it receives a second 180 with a different tag:
>
> ------- SIP/2.0 180 Ringing
>
>    This results in the creation of a second dialog:
>
>
>    <?xml version="1.0"?>
>    <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
>                 version="2"
>                 state="full"
>                 entity="sip:alice at example.com">
>      <dialog id="as7d900as8" call-id="a84b4c76e66710"
>              local-tag="1928301774" remote-tag="456887766"
>              direction="initiator">
>        <state>early</state>
>      </dialog>
>      <dialog id="as7d900as8" call-id="a84b4c76e66710"
>              local-tag="1928301774" remote-tag="hh76a"
>              direction="initiator">
>        <state>early</state>
>      </dialog>
>    </dialog-info> “
>
> The dialog id in the second dialog created should have a different  
> dialogID as specified in section 4.1

thanks, i will fix this.

> 7> The draft talks about the dialog events at the UAs because this is  
> where the dialog state machine exists, but will it be useful to have  
> the capability to monitor such dialogs at a record routing proxy?  So  
> will it be useful to enable a Subscriber SUBSCRIBE to a dialog which  
> is “known” at  a proxy?

proxies in RFC 3261 do not keep track of dialogs or dialog state.   
while you can legally co-locate a dialog state agent with a  
record-routing proxy, this is an implementation detail which is out of  
scope of the document.

> 8> This draft more than other event drafts points towards a need for a  
> mechanism in which a subscription would be required through a non  
> SUBSCRIBE mechanism. This is because the Subscriber in this case may  
> be a party outside of the dialog that needs to monitor and may not  
> know when the dialog came into existence. Of course the subscriber can  
> subscribe before hand, but will still lack the capability to subscribe  
> in real-time to a dialog to which the subscriber may be interested in.
> Will it be worthwhile to add a mechanism by which the subscriptions  
> could also carry over another method like INVITE?
> A new “Subscription” header could carry the subscription and the value  
> of the header may be the target for the subsequent NOTIFY. This could  
> be a non- SUBSCRIBE way of installing subscription. The Event header  
> would then have the required event package.
> If the subscriber is within the trust domain then the NOTIFY’s could  
> start as soon as the first qualifying event occurs rather than waiting  
> for SUBSCRIBE or relying on before-hand subscriptions.
> This feature could be useful for future event users like say an event  
> package for notifying the Voice XML media server interaction state  
> after dialog establishment [e.g. notifications about the digit  
> collection etc. rather than using HTTP route].
>
> In a nutshell this would be useful to a subscriber who cannot know  
> before hand where/whom to subscribe for the events that it is  
> interested in as the dynamic network situations create these event  
> conditions. So the “application” (say a proxy) that knows about the  
> Subscriber and this special condition occurring in the network,  
> inserts this Subscription header and Event header with the subscribers  
> target address.
> If Notifier wants to authenticate the subscriber it could generate a  
> NOTIFY with Subscription-State as “terminated” and  
> reason=auth-required.

The concept of overloading another request (like an INVITE) to add  
subscriptions has been discussed extensively in the past, mostly in the  
context of implicit subscriptions.  It is a big can of worms which is  
clearly out of scope for the dialog package.  If you feel strongly  
about this last point, you may want to write a short draft outlining  
use cases and requirements (I would completely skip the mechanism).

thanks,
-rohan

> Regards
> Nasir Khan
> BEA Systems, Inc.

_______________________________________________
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