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

From: "Dan Wing" <[email-masked]>
Date: Fri, 7 Jul 2006 18:21:21 -0700

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: Shida Schubert <[email-masked]>
Date: Sat, 08 Jul 2006 18:59:49 -0700

I generally like the draft, and I think the work is very important.

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).

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.

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

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 9 Jul 2006 00:27:17 -0400

> I generally like the draft, and I think the work is very important.

Me, too.

> the domain of the UAS might not have AS in place to provide

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.

> 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.

-d

> Last note, looking at the sentence in 6.1 which is shown
> below, I am not sure if
> opinion on this point, but it felt a little funny to mandate
> a behavior with

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 10 Jul 2006 03:41:26 +0200

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:

> backward
> direction following dialog establishment can be wasted if the peer UA 
> (the
> UAC for the INVITE transaction) does not support it. It states:
>
> 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
>
>

---

From: Shida Schubert <[email-masked]>
Date: Sun, 09 Jul 2006 21:15:55 -0700

Hi;

> So I'm not sure of the value such an additional tag would bring
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.
> proxy may validate incoming requests containing Identity signatures.
Agree.

Regards
Shida Schubert

>>>>       "OPEN ISSUE: If the identity has has not changed
>>>>         
>> compared with
>>     
>>>>       option tag is not present in the INVITE request the
>>>>         
>> additional
>>