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 |