Subject: RE: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt

From: "Elwell, John" <[email-masked]>
Date: Sun, 09 Jul 2006 22:27:09 +0100

Dan,

I am not sure that would work. The problem is the UAC typically does not
insert the Identity header field in a request, this is typically done by an
authentication service at the outbound proxy. So the fact that the request
went through an authentication service and had an Identity header field
added does not mean that the response will go through a verification
service. However, I am open to opinions on that.

John

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]] 
> Sent: 08 July 2006 02:21
> To: Elwell, John; [email-masked]
> Subject: RE: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt
> 
> I hadn't noticed any followups to this issue.  I have a suggestion:
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:[email-masked]] 
> > Sent: Tuesday, May 02, 2006 1:21 PM
> > To: [email-masked]
> > Subject: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt
> >
> > The second issue concerns the fact that an UPDATE request in the
> > backward direction following dialog establishment can be wasted if
> > the peer UA (the UAC for the INVITE transaction) does not support
> > it.  It states:
> >
> >       "OPEN ISSUE: If the identity has has not changed compared with
> >       the URI in the To header field and the UAC (for the INVITE
> >       request) does not support verification of an Identity header,
> >       this UPDATE or re-INVITE transaction would fulfil no useful
> >       purpose.  However, the UAS (for the INVITE transaction) does
> >       not know this.  In order to save this round trip, should we
> >       have an additional option tag to indicate support for receipt
> >       of the Identity header on mid- dialog requests?  Then if this
> >       option tag is not present in the INVITE request the additional
> >       transaction could be omitted.  Note that the id-change option
> >       tag does not seem appropriate for this purpose, since a UA
> >       could support a change of URI without supporting Identity."
> >
> > Whilst I do not wish to proliferate option tags, I do see some
> > benefit in such a tag.  Any opinions?
> 
> If an Invite arrives with both Identity and the id-change tag,
> it indicates the offerer understands both Identity and connected-
> identity, so the answerer should generate an request (UPDATE or 
> re-INVITE).
> 
> -d
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 9 Jul 2006 21:12:26 -0400

> I am not sure that would work. The problem is the UAC 
> typically does not insert the Identity header field in a 
> request, this is typically done by an authentication service 
> at the outbound proxy. So the fact that the request went 
> through an authentication service and had an Identity header 
> field added does not mean that the response will go through 
> a verification service. 

I agree there is nothing a UA can do to ensure its request
gets an Identity header added.  

All I'm saying is that if you receive a request with an Identity
headers, there is a pretty darn high likelyhood that the requestor
is interested in having your response authenticated (by a backwards
request using connected-identity).  All you can do is send a request
back to him and hope that your request will get an Identity header
added by your authentication service.  If it doesn't get an Identity
header added, the requestor's local policy or implementation will
decide what to do next: accept the call or drop it (because the
connected-identity response lacks an Identity header).

I argue that an additional tag wouldn't convey any additional 
meaning over my proposal.

-d

> However, I am open to opinions on that.
> 
> John
>