Draft:  draft-ietf-sipping-service-examples-10.txt
Reviewer: Burger, Eric [eburger@cantata.com]
Review Date: Tuesday 6/13/2006 4:01 AM CST
Review Deadline: 7/01/2006
Status: WGLC 
Section: 2.12. Single Line Extension

Summary: 

For the most part, the section is clear and correct.  With the exception
of a major concern about presenting an interoperable call flow,
everything is editorial.  I found no substantial protocols errors.


Main Concern
------------
[See 2nd paragraph of Page 107]
My main concern, and one which may spill into other service examples, is
the example is NOT INTEROPERABLE.  This service example is not
interoperable because it makes service assumptions that cannot be made
in a multi-vendor environment.  For example, the single line extension
service example says, "To avoid this scaling issue, this flow uses an
implicit subscription between each of the group members and a simple
forking proxy."  While this is nice and saves on subscription requests,
there is no way for the devices to KNOW they will get unsolicited
subscriptions.

Using the example from the text, there is no way for B1, B2, and B3 to
know about the implicit registration package subscription and there is
no way for B1 and B2 to know about the implicit dialog package
subscription.  Conversely, B1, B2, and B3 may rely on the proxy
implicitly registering them for the registration package, and the proxy,
following every line of RFC 3261,2,3,4,5, etc., does not implicitly
register them.  There is a similar argument for the dialog package
registration.

I would suggest either:
   (1) Put in explicit subscriptions.  Mention in passing
       that one could create a system with devices that use
       implicit subscriptions if they know the proxy server
       will impose implicit subscriptions on them anyway.
   (2) Keep the call flows as is, but put in a big, bold
       Notice that the call flow is NOT interoperable.

My personal preference is (1) for an IETF publication.  Otherwise, you
can bet some implementers will point to this draft and say, "All User
Agents MUST accept dialog package notifications, whether they subscribe
or not."


Clarification on Operation
--------------------------
[Third paragraph of Page 107, fifth line]
The call flow does the correct thing and shows all of the user agents
receiving the notification.  I would suggest changing the text from:

"B3 sends a NOTIFY containing the dialog information to the AOR for Bob,
which is forked to B1 and B2.  (The service-unaware forking proxy
actually forks it back to B3 as well, but B3 simply discards with a 482
Loop Detected response.)"

To

"B3 sends a NOTIFY containing the dialog information to the AOR for Bob.
Since the proxy is not aware of the service semantics, the proxy forks
the notification to all of Bob's registered user agents B1, B2, and B3.
B3 simply discards the notification with a 482 Loop Detected response."



Nit
---
Page 108, 4th full paragraph, 1st line:
OLD
The use of SUBSCRIBE and NOTIFY is defined in [6] while
NEW
The use of SUBSCRIBE and NOTIFY is defined in [6], while
                                                 ^

Message F11
-----------
Message F11 (Page 112) is from the Proxy to Alice, not from B3 to the
Proxy.
OLD
F11 180 Ringing B3 -> Proxy
NEW
F11 180 Ringing Proxy -> Alice