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

From: "Elwell, John" <[email-masked]>
Date: Mon, 10 Jul 2006 02:53:38 +0100

Dan,

That was not what I was trying to say. The UAC (for the INVITE request) has
no control over whether an Identity header field is added by its domain
proxy. So just because the UAS receives an INVITE request with an Identity
header field, does not mean that the UAC put it there and would be
interested in receiving an UPDATE request with an Identity header field.

However, I don't have a strong objection to the UAS (for the INVITE) always
sending back an UPDATE even if the From header URI would be unchanged from
that in the To header URI of the INVITE request.

Regards,

John 

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]] 
> Sent: 10 July 2006 02:12
> To: Elwell, John; [email-masked]
> Subject: RE: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt
> 
> > 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
> > 
> > > -----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: Mon, 10 Jul 2006 09:25:30 -0400

> That was not what I was trying to say. The UAC (for the 
> INVITE request) has no control over whether an Identity header 
> field is added by its domain proxy. So just because the UAS 
> receives an INVITE request with an Identity header field, does 
> not mean that the UAC put it there and would be interested in 
> receiving an UPDATE request with an Identity header field.
>
> However, I don't have a strong objection to the UAS (for the 
> INVITE) always sending back an UPDATE even if the From header 
> URI would be unchanged from that in the To header URI of 
> the INVITE request.

Cool.  

We could define another Supported tag to optimize this slightly,
(so the UAC indicates it desires connected-identity from the 
UAS) but we're still stuck with the problem that the UAS can't 
ensure its response will get an Identity header.  I don't see
another tag being that beneficial to that slight optimization.

-d