[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Review of draft-ietf-sip-connected-identity-01
Shida,
Thanks for your comments. My responses in-line.
John
> -----Original Message-----
> From: Shida Schubert [mailto:shida at ntt-at.com]
> Sent: 11 September 2006 07:56
> To: sip at ietf.org List
> Cc: Elwell, John
> Subject: [Sip] Review of draft-ietf-sip-connected-identity-01
>
> Draft: draft-ietf-sip-connected-identity-01
> Reviewer: Shida Schubert
> Review Date: 10 Sep 06
> Review Deadline: 18 Sep 06
> Status: Initial review
>
> Summary: This draft is almost ready for publication,
> but needs some clarifications and has nits that should
> be fixed before publication.
>
> The requested clarifications are listed:
>
> - Overall
> As the draft puts so much emphasis on authenticated
> identity that can be verified, I think it would be useful
> to clarify the need of authentication service to provide
> connected identity that's authenticated.
>
> I would go further and possibly describe the implication
> of what it means to receive a conneceted-identity without
> the signature(Although security consideration explains this
> to some detail) and have some text illustrating how even
> when support for "id-change" is indicated, signed
> connected-identity may not be provided due to absence of
> authentication service in connected domain.
[JRE] OK, I will add a bit to the solution overview section.
>
> Draft should also clarify that support for "id-change"
> indicated by UAS does not mean sip-identity will be provided
> in reverse direction.
>
> There is a lot of text related to the discussions that
> took place in the mailing list, I think the draft will be
> a lot easier to read if you can move this out or delete them.
[JRE] I read through it again and the only thing I found to remove was the
paragraph that talks about response identity and use of GRUU. Francois Audet
also suggested deletion of this paragraph. I hope this is sufficient.
>
> Editorial nits:
> --------------------------
[JRE] Done, except where indicated below.
> > Section 3
> - 2nd paragraph, 4th sentence.
> [Remove "clearly"] & [Change "UAS" -> "callee"]
> =OLD=
> "However, this does not necessarily clearly indicate the
> Address of Record (AoR) of the UAS."
> =NEW=
> "However, this does not necessarily indicate the
> Address of Record (AoR) of the callee."
>
> - 4th paragraph, 3rd sentence.
> [Put comma behind "B2BUA"]
>
> - 5th paragraph, 4th sentence.
> [Change "not even any" -> "no"]
> =OLD=
> "In this case there is probably not even any need to
> re-negotiate the session"
> =NEW=
> "In this case there is probably no need to re-negotiate
> the session"
>
> - 6th paragraph.
> [Rearranging the text with list]
> =OLD=
> "This document defines a mechanism for conveying the
> callee identity
> to a caller when a call is answered. The same
> mechanism can be used
> to convey the identity of a user that replaces the
> caller or callee
> following a call re-arrangement such as call transfer.
> In general
> the mechanism delivers connected identity, or the identity of a
> connected user. The same mechanism can also be used to
> convey the
> identity of a potential callee prior to answer.
> =NEW=
> "This document defines a mechanism for conveying
> connected identity,
> or the identity of a connected user and can be used in
> the following
> scenarios.
> - To convey the callee identity to a caller when a call is
> answered.
> - To convey the identity of a user that replacese the
> caller or
> callee following a call re-arrangement such as call
> transfer.
> - To convey the identity of a potential callee prior
> to answer"
>
> > Section 4
> - 2nd paragraph, 2nd sentence.
> [Change "request's source" -> "caller"]
[JRE] I don't agree with this change - the mechanism already available apply
to requests in general (not just INVITE requests).
>
> - 5th paragraph, 3rd sentence.
> [Change "forwarded request" -> "forwarding request"]
[JRE] The existing text is correct.
>
> > Section 5
> - 1st paragraph, 2nd sentence.
> [Add "if the domain supports sip-identity" at the end]
> =OLD=
> "A mid-dialog request is used to provide connected
> identity. The UAC
> for that request inserts its identity in the From header
> field of the
> request and the Identity header field can be used to provide
> authentication."
> =NEW=
> "A mid-dialog request is used to provide connected
> identity. The UAC
> for that request inserts its identity in the From header
> field of the
> request and the Identity header field can be used to provide
> authentication if the domain supports sip-identity"
[JRE] I have handled this differently, by means of text inserted to cover
one of your general comments.
>
> > Section 6.1
> - 1st paragraph, 1st sentence.
> [Change "UA that supports changes of URI in the From and
> To header field during
> a dialog" -> "UAC compliant to this specification"]
>
> > Section 6.2
> - 1st paragraph, 1st sentence.
> [Change "UA that supports changes of URI in the From and
> To header field during
> a dialog" -> "UAS compliant to this specification"]
>
> - 2nd paragraph, 1st sentence.
> [Change "id-change" -> \"id-change\"]
[JRE] I don't understand.
>
> Regards
> Shida Schubert
>
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip