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

From: "Elwell, John" <[email-masked]>
Date: Mon, 10 Jul 2006 12:50:44 +0100

Shida,

I don't think it would work with edge proxies. 

John

> -----Original Message-----
> From: Shida Schubert [mailto:[email-masked]] 
> Sent: 10 July 2006 05:16
> To: Dan Wing
> Cc: Elwell, John; [email-masked]
> Subject: Re: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt
> 
> 
> Hi;
> 
> 
> Dan Wing wrote:
> >> I generally like the draft, and I think the work is very important.
> >>     
> >
> > Me, too.
> >
> >   
> >> Anyhow, AFAIK there is no distinct way to request SIP-Identity to
> >> AS, so just because one receives a sip-identity/id-change tag does
> >> not necessary mean that sender of an UPDATE will be able to send
> >> the sip-identity back(Even if the UAS supports 
> sip-identity/id-change,
> >> the domain of the UAS might not have AS in place to provide
> >> sip-identity).
> >>     
> >
> > Agreed; if we agree we need to optimize that case, we will need
> > an additional option tag.  But, still, there isn't a way for
> > a UAS to "know" that his request will be protected with Identity.
> > So I'm not sure of the value such an additional tag would bring
> > over my suggestion.
> >   
> In past, there has been RFC which proposed the use of 
> proxy-require for
> the next hop only(First hop proxy removes the relevant 
> option-tag in the
> proxy-require). RFC 3329 is one of the example for this, and proposal
> similar to that may be considered.
> >   
> >> This is because there is no option tag to require proxy to add
> >> sip-identity,
> >> and because sip-identity is generally performed at AS, UA 
> is generally
> >> unaware of the domian's support for sip-identity.
> >>
> >> Furthermore, because its the AS that adds sip-identity(except when
> >> UA has its own certificate which I think is unlikely), 
> just because UA
> >> receives the sip-identity, does not necessary mean that UA sending
> >> the original INVITE(offerer that you have described in 
> your comment)
> >> with identity-info header supports sip-identity.
> >>     
> >
> > Even if the original UA itself doesn't support Identity, one of the
> > domain's proxies added the Identity signature and it's likely that
> > proxy may validate incoming requests containing Identity signatures.
> >
> >   
> Agree.
> 
> Regards
> Shida Schubert
> 
> > -d
> >
> >   
> >> Last note, looking at the sentence in 6.1 which is shown
> >> below, I am not sure if
> >> mandating UA to send an UPDATE to update its identity is aligned
> >> with the semantics of Supported header field. I don't really
> >> have a strong
> >> opinion on this point, but it felt a little funny to mandate
> >> a behavior with
> >> a presence of "Supported" header.
> >>
> >> Thanks & Regards
> >> Shida
> >>
> >> Dan Wing wrote:
> >>     
> >>> 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
> >>>
> >>>
> >>>   
> >>>       
> >
> >
> >   
> 

_______________________________________________
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