Hi, a few comments on the following draft:
http://www.ietf.org/id/draft-ietf-bliss-call-completion-05.txt Abstracts should not contain references. Section 1: "So far the following modes of the CC feature have been specified" Where have they been specified? Section 4.1 provides an architectural overview. There is a normative MAY in the second to last paragraph. Does that "may" need to be normative? If so, can we find another place to place it so that Section 4.1 remains an overview of the architecture? Section 4.2 third paragraph s/forward/forwards/ Section 4.2 6th paragraph. The SUBSCRIBE request is sent to "all known monitor URIs". It would be useful to state when and how the caller got those URIs (later in the text, Section 6.2 explains it). Section 4.2 third to last paragraph. The text could clarify that calls are marked as CC calls by using a SIP URI parameter. Section 4.3 first paragraph: s/section 2.17/Section 2.17/ Section 5: create a real reference for RFC 3863. Section 6.2: the text talks about caller's agents that cannot "remember" any monitor URI. Is it supposed to remember those URIs from previous sessions? In the same paragraph, s/the the/the/ Section 7.1 states that the callee's monitor MAY insert a Call-Info header. Instead of using a normative MAY, it would be better to explain that if the callee wants the caller to be able to use the CC service, it needs to insert the Call-Info header field. Cheers, Gonzalo _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
