Hi Dale;
The draft is going through IETF last call not WGLC
so any comments you have should be sent to
[email protected].
Detail review is always welcome but you being a
co-author of the draft, these comments I think should
have been provided sooner to your co-author or
included in the ongoing revision that the draft has
undergone.
Regards
Shida
On Dec 8, 2012, at 6:28 AM, Dale R. Worley wrote:
> Fundamentally, I think the draft is in great shape. The only
> significant change is that I think a summary of the "retain option"
> procedures and considerations should be added so the reader can see
> how it affects the procedures (and how gateways to the PSTN handle
> "retain").
>
> Only items 2 and 19 have technical content; the remainder are
> editorial.
>
> item 1) headers
>
> Can you abbreviate my affiliation on the front page to "Ariadne"? If
> you are using XML2RFC, you can use the 'abrev' attribute of the
> <organization> element:
>
> <organization abbrev='ISI'>
> USC/Information Sciences Institute
> </organization>
>
> item 2) overall
>
> The procedures regarding the retain option are scattered throughout
> the document in a way that makes it difficult to see how it is
> handled. It seems to me that it would be helpful to add a summary of
> retain option processing as a section, perhaps at the end of section
> 4. This allows deleting the last paragraph of section 4.2, which is
> vague when it stands alone.
>
> 4.5 Summary of retain option procedures
>
> When the call completion call fails there are two possible options:
> the CC feature has to be activated again by caller's agent
> subscribing to callee's monitor, or CC remains activated and the
> original CC request remains in the queue.
>
> If the callee's monitor operates in the latter way, it is said to
> support the retain option. Callee's monitors SHOULD support the
> retain option. If a monitor supports the retain option, it SHOULD
> provide the cc-service-retention header in its call-completion
> events. The caller's agent can use this header to know that this
> monitor supports the retain option.
>
> If a callee's monitor does not support the retain option (e.g., if
> it is a gateway to a network device whose CC functionality does not
> support the retain option), it SHOULD NOT provide the
> cc-service-retention header. In addition, after a failed CC call
> that causes the CC request to be deleted from the queue, the
> monitor MUST terminate the corresponding agent's subscription to
> inform the agent that its CC request is no longer in the queue.
>
> After a failed CC call, the caller's agent MAY terminate its
> subscription, to inform the monitor that it is terminating its CC
> request. After a failed CC call, the caller's agent MAY receive a
> termination of its subscription from the callee's monitor, if the
> monitor has terminated the agent's CC request. In either case, the
> agent MAY create a new subscription (as described in section 6.2)
> to create a new CC request for the same original call. The agent
> SHOULD avoid terminating one subscription and creating a new one if
> the caller's monitor has indicated support of the retain option.
>
> I have used SHOULD to describe procedures which are desirable but are
> not required for correct functioning. In particular, the
> cc-service-retention value does not have to be correct for a
> properly-implemented agent and monitor to interact correctly. This
> gives us some freedom in situations where a gateway cannot discern
> accurately whether the ultimate callee supports the retain option or
> not.
>
> Pure SIP agents and monitors can implement all the SHOULD behaviors
> straightforwardly, so in the pure-SIP case, CC is done with the retain
> option, which is what we want.
>
> item 3) section 4.1
>
> The callee's monitor maintains information about the set of INVITEs
> received by the callee's UA(s) considered unsuccessful by the caller.
>
> Strictly speaking, the monitor can't know if an INVITE is considered
> unsuccessful by the caller. This wording might fix that:
>
> The callee's monitor maintains information about the set of INVITEs
> received by the callee's UA(s) that the caller might consider
> unsuccessful.
>
> item 4) section 4.2
>
> The callee's monitor
> keeps a list or queue of the caller's agent's subscriptions,
> representing the requests from the caller's agent to the callee's
> ---------------------------------------------------^
> should be "agents"
> monitors for call-completion services.
> ----------^
> should be "monitor"
>
> item 5) section 4.2
>
> When the callee's monitor determines the callee and/or callee's UA
> insert "are" here
> available for a CC call, it selects a caller to execute the CC call
> and sends a call-completion event update (''cc-state: ready'') via a
> ---------------------------------------------^^
> this should probably use " rather than ''
> NOTIFY request to the selected caller's agent's subscription, telling
> it to begin the CC call to the callee's UA.
>
> item 6) section 4.2
>
> When the call completion call fails there are two possible options:
> the CC feature has to be activated again by caller's agent
> subscribing to callee's monitor, or CC remains activated and the
> original CC request retains its position in the queue if retain
> option is supported.
>
> This is kinda vague. See item 2.
>
> item 7) section 4.3
>
> There is no interaction between call completion and automatic redial,
> -----------------------------------^
> There is a risk of confusion. I think this could be clarified as
>
> There is no interaction between automatic redial and call
> completion (as defined in this document), as they use different
> event packages and specify different behaviors regarding the
> events.
>
> item 8) section 5
>
> Each CCE has an availability state, determined through caller's
> presence status at the callee's monitor. A presence status of
> ''open'' represents CCE's availability state of 'available' and a
> ---^^
> this should probably use " rather than ''
> presence status of "closed" represents CCE's availability state of
> 'unavailable'.
>
> item 9) section 5
>
> A CCE is identified by the
> request-URI (if it was taken from a call-completion event
> --------------^^^^^^^
> I think this would be clearer as
>
> request-URI of the PUBLISH request (if that URI was taken from a
> call-completion event
>
> item 10) section 5
>
> notification which identifies the CCE) or the From URI of the request
> (matching the From URI recorded in the CCE).
>
> state of the CCE to 'not-available' (suspend).
> ------------------------^^^^
> Other locations in the text use the value 'unavailable'.
>
> item 11) section 7.1
>
> The callee's monitor SHOULD insert a URI in the Call-Info header
>
> Since the first sentence of the previous paragraph specifies "MUST"
> regarding inserting Call-Info, this "SHOULD" would be better specified
> as "MUST".
>
> item 12) section 7.1
>
> The 'm' parameter defines the "mode" of call completion. The "m=NR"
> parameter indicates that it failed due to lack of response, the
> ----------------------------^^
> this "it" should be "the original call"
> "m=BS" parameter indicates that it failed due to busy subscriber, and
> -----------------------------------^^
> the latter two "it"s are probably unambiguous
> the "m=NL" parameter indicates that it failed due to non registered
> ---------------------------------------^^
> subscriber (no devices are registered for the AoR contacted). The
>
> item 13) section 7.4
>
> The callee's UA(s) and the callee's monitor may give the CC call
> precedence over non-CC calls by evaluating the presence of the 'm'
> URI parameter and the From header of the INVITE request.
> -----------------^^^
>
> I don't think this "and" is correct. One possibility is:
>
> The callee's UA(s) and the callee's monitor may give the CC call
> precedence over non-CC calls by evaluating the presence of the 'm'
> URI parameter in the From header of the INVITE request.
>
> item 14) section 7.5
>
> the retain option and terminate the subscription along with the queue
> if it doesn't support the retain option. Similarly, if the CC call
> I think "queue" is supposed to be "CCE".
>
> item 15) section 7.5
>
> completion" events, or any URI it returns as the "URI" line of the
> ---------------------------------------------^^
> I think this is supposed to be "in".
>
> item 16) section 7.5
>
> The receipt of the PUBLISH request initiates a presence event state
> for the caller's identity at the presence server functionality of the
> callee's monitor as specified in [RFC3903] , together with a logical
> presence server if this has not been done before for another call.
>
> Note: The presence server may initiate a presence event state for the
> caller's identity at the receipt of SUBSCRIBE request as well,
> dependent on the implementation.
>
> These paragraphs do not match the following paragraph from 4.2:
>
> Upon receiving a SUBSCRIBE request from the caller's agent, the
> callee's monitor instantiates a presence state for the caller's UA
> which can be modified by the caller's UA to indicate its availability
> for CC call. The status at the presence upon instantiation is
> "open".
>
> Also, this section doesn't explicitly specify what is happening: The
> first sentences need to say that suspend requests are PUBLISH with
> status 'closed'. Somewhere in this section it needs to be mentioned
> that the CCE is set to 'unavailable'.
>
> item 17) section 7.6
>
> Similarly to 7.5, the first sentences need to say that suspend
> requests are PUBLISH with status 'closed'. Somewhere in this section
> it needs to be mentioned that the CCE is set to 'unavailable'.
>
> The final sentence seems to be incorrect in some cases:
>
> If the callee
> is not busy and there is no entry in the CC queue which is currently
> being processed, the callee's monitor MUST process the queue as
> described in section 7.3 above.
>
> because the callee's policy may not allow any CCE to be recalled at
> this time. (For example, if a recall for that CCE has recently
> failed.)
>
> Assembling these changes, I think something like this would be better:
>
> A CC request is resumed by a PUBLISH request from caller's agent as
> described in section 6.6, that is, containing a 'state' of 'open'.
> The presence event state for the caller's identity at the presence
> server functionality of the CC monitor MUST be updated as described
> in [RFC3903], and the corresponding CCE's availablity state must be
> set to 'available'. This may cause the CCE to be selected for
> recall under the monitor's policy.
>
> item 18) section 8
>
> In the second example, I see two uses of "Content-Type: 'app/pidf'".
> I think this should be spelled out as "Content-Type: application/pidf".
>
> For the bodies, I think it would be safer to spell out the PIDF a bit
> more:
>
> | Body: ...<status><basic>open</basic></status>...
>
> item 19) section 10.3
>
> The cc-URI line provides a URI (possibly in the form of a name-addr)
>
> but it also says
>
> cc-URI = "cc-URI" HCOLON addr-spec
>
> There are three choices for the syntax of the value of cc-URI:
>
> addr-spec
> this eliminates the possibility of generic-params ("header parameters")
> name-addr
> this allows generic-params but requires that we rephrase the
> first sentences of the section, as a name-addr isn't a URI, strictly
> speaking.
> addr-spec / name-addr
> this alternative is used a lot in headers, but we would have
> to mention that the rule in RFC 3261 section 20.10 applies:
>
> Even if the "display-name" is empty, the "name-addr" form MUST be
> used if the "addr-spec" contains a comma, semicolon, or question
> mark. There may or may not be LWS between the display-name and the
> "<".
>
> Looking at the old drafts, we changed the value from "(name-addr /
> addr-spec)" to "addr-spec" in -15. So the ABNF is probably correct.
> So we should reduce the text of this section to just the first three
> sentences:
>
> The cc-URI line provides a URI (possibly in the form of a name-addr)
> which the agent SHOULD use as the request-URI of the CC recall INVITE
> and the suspend/resume PUBLISH. It SHOULD be provided in all
> NOTIFYs. The URI SHOULD be globally routable and SHOULD uniquely
> identify the CCE in question.
>
> item 20) section 12.2
>
> Intended usage: LIMITED USE
>
> We could expand this to:
>
> Intended usage: Within the procedures of RFC XXXX.
>
> item 21) section 12.4
>
> Reference: [RFC3261].[RFC5367][[RFC XXXX]]
> -----------------------^
>
> I think this is intended to be a comma.
>
> Dale
> _______________________________________________
> BLISS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
