Subject: [BLISS] Comments on draft-ietf-bliss-call-completion-05.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 05 Mar 2010 12:13:37 +0200

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

---

From: <[email-masked]>
Date: Mon, 8 Mar 2010 17:02:31 +0100

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-masked] [mailto:[email-masked]] 
> Im Auftrag von Gonzalo Camarillo
> Gesendet: Freitag, 5. März 2010 11:14
> An: [email-masked]
> Betreff: [BLISS] Comments on draft-ietf-bliss-call-completion-05.txt
> 
> Hi,
> 
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 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.
> 
> "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.

> 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-masked]
> https://www.ietf.org/mailman/listinfo/bliss
>