Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Brian Carpenter
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Ted Hardie
2005-10-18
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-10-12
05 Amy Vezza IESG state changed to Approved-announcement sent
2005-10-12
05 Amy Vezza IESG has approved the document
2005-10-12
05 Amy Vezza Closed "Approve" ballot
2005-10-06
05 Allison Mankin State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Allison Mankin
2005-10-06
05 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2005-10-06
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-10-06
05 (System) New version available: draft-ietf-sipping-callerprefs-usecases-05.txt
2005-08-31
05 Ted Hardie
[Ballot discuss]
After discussion with Paul, some updates:

For Section 3.1.2, Paul will confirm whether  sip.methods or methods is correct for the
examples, and he …
[Ballot discuss]
After discussion with Paul, some updates:

For Section 3.1.2, Paul will confirm whether  sip.methods or methods is correct for the
examples, and he will confirm whether the quotes are needed for "INVITE" etc. 

For Section 6, Paul has confirmed that the authors' intent is not to describe a new algorithm,
but to indicate which parts of the 2533 set intersection mechanisms are not needed in
an implementation which will only handle the limited types of set which 3840 & 3841 described.
He will work with Jonathan to update the text in section 6 to describe the aim/intent, and he will
update the terms to avoid re-using terms which have existing meanings in the referenced docs.
2005-08-19
05 (System) Removed from agenda for telechat - 2005-08-18
2005-08-18
05 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2005-08-18
05 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2005-08-18
05 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2005-08-18
05 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen
2005-08-18
05 Brian Carpenter [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Discuss by Brian Carpenter
2005-08-18
05 Brian Carpenter
[Ballot comment]
Editorial comments from Elwyn Davies:

Use of 'callerprefs':  This is a convenient shorthand, but it is used in
a fairly arbitrary way.  I …
[Ballot comment]
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/
2005-08-18
05 Brian Carpenter
[Ballot discuss]
Review by Elwyn Davies has raised this point - awaiting response
from the authors:

s6.1/s6.2: RFC2533 s4.2.5 allows the 'set construct' to combine …
[Ballot discuss]
Review by Elwyn Davies has raised this point - awaiting response
from the authors:

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.
2005-08-18
05 Brian Carpenter [Ballot Position Update] New position, Discuss, has been recorded for Brian Carpenter by Brian Carpenter
2005-08-17
05 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-08-17
05 Ted Hardie
[Ballot discuss]
Section 3.1.2 discusses the construction of an implicit require-flagged Accept-Contact, and points
to RFC 3841, Section 7.2.2 as the source of the …
[Ballot discuss]
Section 3.1.2 discusses the construction of an implicit require-flagged Accept-Contact, and points
to RFC 3841, Section 7.2.2 as the source of the construction.  The examples used, however, don't
match.  In this document, the construction is:  (& (methods="INVITE")), where the RFC 3841 example
construction from 7.2.2  is: 
    (& (sip.audio=TRUE)
        (sip.video=TRUE)
        (sip.mobility=fixed)
        (sip.message=TRUE)
        (| (sip.methods=INVITE) (sip.methods=OPTIONS) (sip.methods=BYE)
            (sip.methods=CANCEL)ip.methods=ACK))
        (| (sip.schemes=sip) (sip.schemes=http)))

Why is the example in this spec not (& (sip.methods=INVITE))?  The examples given in
this document do not, in general, seem to match the examples in 3841.

In section 3.4.2, the document says:

  (& (methods="SUBSCRIBE") (events="presence"))

  This predicate matches Y1..Yn and Yp.  However, the score for Y1..Yn against this
  predicate is 0.5, and the score of Yp is 1.0.

The registration above does not seem to assign any q-values, which should create a
default q-value of 1.0.  Is there a missing q-value in the registration text?


In section 3.16.2, the document says:


  An explicit option is not used, because it would bypass contacts that
  do not include a language tag.

Bypassing contacts that did not include language tag actually seems to be the desired
behavior for this use case, unless the caller believes the base state to be bilingual fluency.

Section 6.2 says:

  Here we use a representation for the value of a feature parameter
  consisting of a set of feature value-ranges, each containing:
  o  A type: token, string, number-range
  o  A negation flag: negated, non-negated
  o  The actual value, differing by type:
      *  For tokens and strings, a sequence of bytes
      *  For number-range, a pair of signed real numbers representing
        the lower and upper bounds on the range, inclusive

Note that the sequence of bytes for tokens and strings does not match 2533:

      token      =  ALPHA *( ALPHA / DIGIT / "-" )
      string    =  DQUOTE *(%x20-21 / %x23-7E) DQUOTE
                    ; quoted string of SP and VCHAR without DQUOTE

I understand that this is not meant to be normative, but I believe you'd still have
to describe what happens if the "sequence of bytes" fails to conform to the base
set of allowed characters.
2005-08-17
05 Ted Hardie
[Ballot discuss]
Section 3.1.2 discusses the construction of and implicit require-flagged Accept-Contact, and points
to RFC 3841, Section 7.2.2 as the source of the …
[Ballot discuss]
Section 3.1.2 discusses the construction of and implicit require-flagged Accept-Contact, and points
to RFC 3841, Section 7.2.2 as the source of the construction.  The examples used, however, don't
match.  In this document, the construction is:  (& (methods="INVITE")), where the RFC 3841 example
construction from 7.2.2  is: 
    (& (sip.audio=TRUE)
        (sip.video=TRUE)
        (sip.mobility=fixed)
        (sip.message=TRUE)
        (| (sip.methods=INVITE) (sip.methods=OPTIONS) (sip.methods=BYE)
            (sip.methods=CANCEL)ip.methods=ACK))
        (| (sip.schemes=sip) (sip.schemes=http)))

Why is the example in this spec not (& (sip.methods=INVITE))?  The examples given in
this document do not, in general, seem to match the examples in 3841.

In section 3.4.2, the document says:

  (& (methods="SUBSCRIBE") (events="presence"))

  This predicate matches Y1..Yn and Yp.  However, the score for Y1..Yn against this
  predicate is 0.5, and the score of Yp is 1.0.

The registration above does not seem to assign any q-values, which should create a
default q-value of 1.0.  Is there a missing q-value in the registration text?


In section 3.16.2, the document says:


  An explicit option is not used, because it would bypass contacts that
  do not include a language tag.

Bypassing contacts that did not include language tag actually seems to be the desired
behavior for this use case, unless the caller believes the base state to be bilingual fluency.

Section 6.2 says:

  Here we use a representation for the value of a feature parameter
  consisting of a set of feature value-ranges, each containing:
  o  A type: token, string, number-range
  o  A negation flag: negated, non-negated
  o  The actual value, differing by type:
      *  For tokens and strings, a sequence of bytes
      *  For number-range, a pair of signed real numbers representing
        the lower and upper bounds on the range, inclusive

Note that the sequence of bytes for tokens and strings does not match 2535:

      token      =  ALPHA *( ALPHA / DIGIT / "-" )
      string    =  DQUOTE *(%x20-21 / %x23-7E) DQUOTE
                    ; quoted string of SP and VCHAR without DQUOTE

I understand that this is not meant to be normative, but I believe you'd still have
to describe what happens if the "sequence of bytes" fails to conform to the base
set of allowed characters.
2005-08-17
05 Ted Hardie
[Ballot discuss]
Section 3.1.2 discusses the construction of and implicit require-flagged Accept-Contact, and points
to RFC 3841, Section 7.2.2 as the source of the …
[Ballot discuss]
Section 3.1.2 discusses the construction of and implicit require-flagged Accept-Contact, and points
to RFC 3841, Section 7.2.2 as the source of the construction.  The examples used, however, don't
match.  In this document, the construction is:  (& (methods="INVITE")), where the RFC 3841 example
construction from 7.2.2  is: 
    (& (sip.audio=TRUE)
        (sip.video=TRUE)
        (sip.mobility=fixed)
        (sip.message=TRUE)
        (| (sip.methods=INVITE) (sip.methods=OPTIONS) (sip.methods=BYE)
            (sip.methods=CANCEL)ip.methods=ACK))
        (| (sip.schemes=sip) (sip.schemes=http)))

Why is the example in this spec not (& (sip.methods=INVITE))?  The examples given in
this document do not, in general, seem to match the examples in 3841.
2005-08-17
05 Ted Hardie [Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Ted Hardie
2005-08-17
05 Michelle Cotton IANA Comments:
As described in the IANA Considerations section, we understand this document to have NO IANA Actions.
2005-08-17
05 Allison Mankin [Ballot Position Update] New position, Yes, has been recorded for Allison Mankin
2005-08-17
05 Allison Mankin Ballot has been issued by Allison Mankin
2005-08-17
05 Allison Mankin Created "Approve" ballot
2005-08-17
05 (System) Ballot writeup text was added
2005-08-17
05 (System) Last call text was added
2005-08-17
05 (System) Ballot approval text was added
2005-08-10
05 Allison Mankin State Changes to IESG Evaluation from AD Evaluation by Allison Mankin
2005-08-10
05 Allison Mankin Placed on agenda for telechat - 2005-08-18 by Allison Mankin
2005-08-10
05 Allison Mankin
Ask for a few AD eval changes: 
  Registers should show up as TLS (it's a SHOULD)
  Would the names of the hosts be …
Ask for a few AD eval changes: 
  Registers should show up as TLS (it's a SHOULD)
  Would the names of the hosts be role-oriented (this is not great practice)?
  Point to discussion of conflicts
2005-08-10
05 Allison Mankin State Change Notice email list have been change to gonzalo.camarillo@ericsson.com, rohan@ekabal.com, dean.willis@softarmor.com from gonzalo.camarillo@ericsson.com, dean.willis@softarmor.com, rohan@ekabal.com
2005-08-03
05 Allison Mankin [Note]: 'PROTO shepherd gonzalo.camarillo@ericsson.com' added by Allison Mankin
2005-08-03
05 Allison Mankin State Changes to AD Evaluation from Publication Requested by Allison Mankin
2005-06-20
05 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2005-05-18
04 (System) New version available: draft-ietf-sipping-callerprefs-usecases-04.txt
2004-10-25
03 (System) New version available: draft-ietf-sipping-callerprefs-usecases-03.txt
2004-07-20
02 (System) New version available: draft-ietf-sipping-callerprefs-usecases-02.txt
2004-02-17
01 (System) New version available: draft-ietf-sipping-callerprefs-usecases-01.txt
2003-07-02
00 (System) New version available: draft-ietf-sipping-callerprefs-usecases-00.txt