Hi Gonzalo,
thanks for the comments, please find some answers inside. The corrections and proposals for clarifications are noted for the revision. Regards, Martin > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:[email protected]] > Im Auftrag von Gonzalo Camarillo > Gesendet: Freitag, 5. März 2010 11:14 > An: [email protected] > Betreff: [BLISS] Comments on draft-ietf-bliss-call-completion-05.txt > > 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? I agree this is misleading, it should state "This draft defines the following CC features:". > > 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? It should be changed to "can". > > 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? A caller's agent should renember the Monitor URI if it was received in the Call-Info header which informs about the possibility for call completion. But there might be 'simple' agent which are not capable to do so, an example is a PSTN gateway. > > 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. I agree this should be reworded. > > > Cheers, > > Gonzalo > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
