Draft: draft-ietf-sipping-callerprefs-usecases-04.txt Reviewer: Elwyn Davies [elwynd@dial.pipex.com] Review Date: Tuesday 8/16/2005 6:43 AM CST Telechat Date: Thursday 8/18/2005 Summary: There is one issue that needs to be cleared up. This is whether the algorithm in s6 covers 'set construct' values properly - it seems to leave them out of consideration and only allow a single range. There are also a number of editorial nits that need to be fixed. The whole business of preference values and predicates, although clearly useful, is immensely complicated and it may be difficult to demonstrate interoperability properly, especially in the more general case. I think that this is another area in which (another) set of torture tests could be usefully generated - this document is a useful starting point. I know we don't do interoperability testing, but... I am also sure that debugging a set of user defined preferences in anything but the simplest case may be difficult. Is this a case where an 'events' package could help? I envisage this might allow a user to obtain information about what happened when a call was processed in a way that didn't meet the callee's expectations based on the preferences he had (supposedly) expressed (i.e., was delivered to the wrong agent, or worse still rejected inappropriately, according to his internal view of the world), by returning any generated implicit predicates, some of the calculated values and ordered candidate sets that resulted during the process. Local output of these values is going to be essential to a developer trying to check an implementation so there wouldn't be an awful lot of work involved. Review: ------- Substantive: s6.1/s6.2: RFC2533 s4.2.5 allows the 'set construct' to combine multiple values in a predicate. I noted that RFC3841 restricts predicates to contain only one instance of a feature parameter. I am not clear whether the algorithm presented here continues to work in the face of set construct values for a single instance of a feature parameter. It may well do, but some additional words may be needed. The representation in s6.2 doesn't seem to be quite right for the set construct value. Editorial nits: Use of 'callerprefs': This is a convenient shorthand, but it is used in a fairly arbitrary way. I think it could be spelt out in full usefully in the seven or so instances where it is used. s1: para 2: s/an compendium to/a compendium of examples of the usage of/ s3 throughout: The terms require-flagged and require-tagged are used apparently interchangeably and without explicit definition. Use one or the other and define what is meant on the first occasion. s3 throughout: The angle brackets are missing from round the address in a miscellaneous subset of the 'Contect:' example lines starting with two in section 3.9.2. s3: usage of automaton (singular) and automata (plural/feature tag): Usage is inconsistent. s3.14.1, para 2 of s3.14.2, last para of s3.17.2 (3 places), s3.18.2 should all use 'automaton' rather than 'automata'. Arguably the feature tag should have been 'automaton' but that is doubtless too late to argue. s3.1.1: In this section the phone 'supports the standard operations... BYE, and so on' (indefinite) whereas in s3.2.1 the phone 'supports the INVITE,... and ACK methods' (definite). s3.3.1 uses different words again. There doesn't seem to be a reason for the difference and it would be good (if boring) to make the phraseology consistent unless there is good reason not too. s3.1.2: para after (& (methods="INVITE"): s/its require flag/its 'require' flag/, a/Y2 is discarded/Y2 is eliminated/ Generally: The word 'discarded' doesn't feel right ... I know what you mean but it has too permanent a flavour. 'Eliminated' or 'ignored' would be better. (In fact I discover eliminated is used in s3.3.2) s3.2.2: last para: The throwaway mention of q-value is confusing. It would be desirable to include q values in the Contact registration examples if it is of consequence or remove the comment it is not. If the q-value affects the choice, which it apparently does, it would be good to have a simple use case where the choice is made just on the q-value even though it is used a lot later. Going back to the case of s3.2.2, the discussion of q-value raises the question of what happens if there are multiple possibilities (rather than just one as in the use case) and none of them match - a pointer to the discusion in RFC3841 would help as well as a pointer to the original definition of 'q' in RFC3261 and maybe some of the matter in RFC2533 s3.6 - but I am still unclear as to whether the message is forked to all possibilities or just sent to the highest q-value equivalence set. [Aside: I have to say that q or qvalue or q-value - take your pick according to which document you are looking at - is poorly indexed. It took me 10 minutes of searching to find out that "q" was a parameter of Contact (s20.10 of RFC3261) but only when in a registration and q-value or qvalue was the value assigned to this parameter. The default value of 1.0 only seems to appear in RFC3841.] s.3.3.2/3.4.2: A reference to RFC3841 s.7.2.4 would help. s3.5.1: s/called answered/call answered/ s3.5.2: s/To have the call is preferentially/To have the call preferentially/ s3.6.2: s/didn't say anything about support/did not explicitly register support/ s3.7.1: add (3pcc) after 'Z is a third party call controller' to define abbreviation. s3.8.2: last para: s/explict/explicit/ s3.9.2: The angle brackets are missing from Y1 and Y2-es Contact lines. (this is only the first of several cases of this--- check them all) s3.9.2: para 3: s/A user at a phone Y2 that speak/A user at phone Y2 that speaks/ s3.9.2: para 12: s/This matches all Y1 phones/This matches the Y1 phone/, s/Y3 phones/the Y3 phone/ (there is only one of each, allegedly). s3.11.2: last para: might be worth noting that this is the case when a 480 error is (correctly and usefully) returned by the proxy. s3.13.2: CPL is an unexpanded acronym. s5.3: last para: s/extensiosn/extension/