Draft: draft-ietf-sipping-dialogusage-03 Reviewer: Paul Kyzivat [pkyzivat@cisco.com] Review Date: Monday 9/11/2006 8:18 PM CST Review Deadline: 10/02/2006 Status: WGLC Summary: -------- This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: --------- I went through the whole -03 version this afternoon. We are down to nit picking time, so I have a bunch of stuff, but it largely only affects form, not the message. This is an important draft and the meat is the right meat. Section 1: The label for Figure 1 is really hard to see in the position it ended up. (Same is true for Figure 2.) I think it is because it is placed after the message detail. I think it would be better right after the flow diagram. The second paragraph includes: "Multiple REFERs within a dialog create multiple subscriptions, each of which is a new dialog usage sharing common dialog state." While this is true, it might be confusing. After sending a REFER, it would not be normal to send another until the first either succeeds or fails. Upon either success or failure, it would be normal for the refer subscribe usage to terminate as well. So in a normal case I think you would not normally have multiple *concurrent* refer subscribe usages. It would be possible (for instance the first usage might not end when the REFER succeeds) but that would be "weird". Since the point here in the introduction is simply to motivate multiple usages, maybe some other more plausible example would be less confusing. An example might be: A invites B, B subscribes to KPML of A, B sends REFER to A. This results in an INVITE usage and two subscribe usages in different directions for different events. Another could be: A invites B, B subscribes to KPML of A, A subscribes to KPML of B. I'm pretty sure I know both of these have been implemented, so I guess they are plausible. Also in section 1: "Usages have state that is not shared in the dialog. For example, a subscription has a duration. Multiple subscriptions in the same dialog each have their own duration." This is again true, but possibly misleading by omission, in that a subscription usage has other state. In addition to duration it has: event type, event id, and a direction. I think either this should be mentioned, or to avoid that complexity it might be ok to say: "For example a subscription has, among other things, a duration." Section 2.2: para 1 nit: s/For space,/To focus on the essential points,/ para 2 nit: s/decides skip/decides to skip/ In figure 2 I question the termination point for usage 1. Based on the content of section 3.2 it will end on the 200 response to the NOFIFY following F3 rather than on the 200 of the unsubscribe. Section 3.2: Says that a usage is created by 2xx response to SUBSCRIBE, as well as NOTIFY. I think there is some debate whether the 200 actually does create a usage, or if it is only the NOTIFY that does so. Says terminated by 2xx response to NOTIFY-terminated. As noted before this contradicts the termination of usage 1 in figure 2. (Question: is it also terminated if a NOTIFY is not received reporting the expiration of the subscription? If so, when? If too soon then the final NOTIFY will not be processed.) Section 4.1: I think this section could be drastically shortened, simplified, and made easier to comprehend by removing the redundancy. The vast majority of the responses are treated the same as 400 - they affect only the request and don't change status of usage or dialog except by changing the CSeq. But this is said in many different ways. For the most part there are only three outcomes: - impacts only transaction, not usage or dialog - terminates usage, not dialog - terminates dialog and all usages Over and above that, there are some nuances that are worth bringing out for some particular responses. I think this might be handled most concisely by a table with a row for each response. It would indicate which of the the three general treatments apply to it, with an indication if there are special considerations for that one. Then there can be additional text, following the table, for each one that has some special considerations to note. In discussion of 400: s/complaint/compliant/ In discussion of 403: This means it is impossible to explicitly request termination of the subscription. If the goal was to announce termination of the subscription, what should be done? I think the best that is possible is for the UAC to declare the usage ended, while the UAS will not know it is ended until it attempts to send something else in the usage and receives a 481 response. Discussion of 483 says "the the agent should attempt to gracefully terminate this usage and all other usages that share its dialog." It is not clear from this language if that means additional signaling should be attempted to achieve this graceful termination, or whether only local actions should be taken. Remote actions don't seem useful in this case. Would be good to be explicit about it. Perhaps say something like: "the agent should terminate this and all other usages as gracefully as is possible without sending further messages in the dialog." Whatever the final language is, it applies to several responses. Discussion of 500: here talks about attempting to gracefully terminate a usage or treat it as terminated. Not clear what the difference between these is. Similar to comment about 483. Section 4.4: It might be worth noting that it is problematic to send a message for a different usage between the time the target refresh request is sent and the time a final response to it is sent or received. During this period its impossible to know which target is active at the other end. (Of course this applies to requests within a usage too, but people might not of considered it in this context.) I would say that this should be left to the race-conditions draft, but its trying to avoid dealing with multiple usages. Section 5: When designing new applications that use SIP dialogs, do not construct multiple usages. If a peer attempts to create a second usage inside a dialog, refuse it. I think there can be some ambiguity in what is meant by the term "new application". When I first read this, I was thinking it meant "a new implementation of a UA". So I thought you were suggesting that new implementations of a UA, when implementing transfer, should refuse to support multiple usages. This is an excellent way to create interop problems. After thinking about it I decided you couldn't possibly mean that, and that you must be talking about designing new features for which there are no existing implementations. In that case I agree it is fine to avoid using multiple dialog usages. Right this second I don't have any wording in mind that gets the point across without being too verbose, but I am certain it must be possible. When designing a new feature that will require new implementation by all participating UAs, avoid usage of multiple dialogs. I still struggle with the part about refusing attempts to create a second usage because I am not certain that you can always know whether the peer is trying to carry out the new feature, or an old feature in the same context. I'm sure it is possible to construct some more specific guidelines, but I think it will take some work to get them right. Section 5: The paragraph before the call flow says: "A new header, Target-Dialog: perhaps". The "perhaps" seems wrong here. Maybe it was included before the RFC 4538 was complete. Now there probably should be a reference to that RFC. In the message detail for figure 3, the stuff for gruu is not consistent with the latest draft. Minimally the gruu URIs should have a "gruu" uri parameter, and the "Supported:gruu" can then be omitted. (That is probably sufficient for this example.) The paragraph: Message F2 lets Alice know that Bob understands GRUUs. If Bob did not indicate this support, the original multi-usage approach to transfer would have to be used. is now not quite right either. Neither Alice nor Carol need to know that bob understands gruus for this scenario to work. Its bob that needs to know Alice and Carol support gruu. Bob learns that from the gruu parameter in the Contacts in messages F1 and F4. If alice doesn't support then the R-URI for the REFER should be Alice's AOR, and if carol doesn't support then the Refer-To should be carol's AOR. Of course this may change as a result of the WGLC on gruu. (I was going to try to provide replacement text for this, but I can't do it piecemeal. It needs a bunch of small changes distributed through it. I can attempt the whole thing if you want. Section 6 - Security Considerations: I find the warnings in the first paragraph to be excessively dire. I see two kinds of exploits by an "evil doer": - MiTM attack. If the bad guy can get into a position to inject messages into the dialog, then it can attack multiple usages rather than just one. But if it could get into one dialog, why not another? This seems to be a matter of only doing something quickly before the bad guy can crack your security. It could be quick with one usage or several. So I don't see the significance of this exploit as something special to multiple usages. - At the UAC or UAS, there might be some kind of multiplexer that combines usages into a single dialog. If the code implementing the various usages is otherwise independent and untrusting of the code implementing the other usages, then there is a threat that malice or incompetence in an application implementing one usage could screw up a different usage. But that isn't really a fault against multiple usages, it is the fault of multiple usages in differing trust domains. This is a kind of implementation scope that isn't often addressed in the sip specifications, so I don't know why it would be addressed here. But if it is, I think the scope should be suitably narrowed. I expect that the more common case is that all the usages are implemented within the same "application".