Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension
draft-ietf-sipping-callerprefs-usecases-05

Editorial comments from Elwyn Davies:

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/