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

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

Hisham,

Well that was how I had it originally, but I was asked to consider
separating it. I don't have a strong opinion.

John 

> -----Original Message-----
> From: Hisham Khartabil [mailto:[email-masked]] 
> Sent: 10 July 2006 02:41
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt
> 
> What is the point of supporting id-change without supporting 
> Identity. 
> If you support connected-identity, then you MUST support 
> Identity RFC. 
> That's it.
> 
> Hisham
> 
> On May 2, 2006, at 10:21 PM, Elwell, John wrote:
> 
> > 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?
> >
> > John
> >
> >
> > _______________________________________________
> > 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

---

From: Shida Schubert <[email-masked]>
Date: Sun, 09 Jul 2006 22:07:11 -0700

Hi;

I think they may have separate semantics. I see "id-change" tag
marely defines the ability to express ones ability to withstand the
change of From.

Usage of sip-identity along with id-change to provide authenticated
connected identity is defining a usage of id-change. I think it's important
to describe the usage somewhere. Where? I don't know.. .

As discussed on this thread, id-change is used by the end-device
and sip-identity as I can foresee will be likely to be deployed on the
proxy.

So support "id-change" also means support "sip-identity" may not work
too well.

Regards
Shida