Subject: RE: [Sip] draft-cao-sip-response-identity-00.txt

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 29 Mar 2006 14:28:55 +0100

(as chair)

Currently we have agreement from the face-to-face meeting that the concepts in connected identity are sufficiently well agreed to make it into a deliverable from the working group. That is we have a set of solutions that address the requirements in this area. We are confirming that decision on the mailing list.

For draft-cao-sip-response-identity-00.txt we currently have no consensus about the mechanisms in the draft at all. What we heard in the face-to-face meeting was cpnsiderable disagreement about whether some of the requirements could be solved at all. We need to achieve that consensus before we can agree that this should be either a separate WG item or within an existing one.

We do not plan to make any decision about the documentation of draft-cao-sip-response-identity-00.txt until there is some consensus on the mechanisms proposed and support for moving forward. At the moment there have been no posts in favour or against achieving that consensus, and at the moment all we can assume is that there is no support for solving this problem at all. 

regards

Keith

> -----Original Message-----
> From: Rocky Wang [mailto:[email-masked]]
> Sent: 29 March 2006 04:36
> To: 'Drage, Keith (Keith)'; [email-masked]
> Subject: RE: [Sip] draft-cao-sip-response-identity-00.txt
> 
> 
> Hi, Keith,
>     As far as I considered, from the functinality and 
> requirement aspects, I
> feel it is useful to return back the responser idtifier as well. Is is
> possible to mrege the requirements of in both the drafts 
> together? I means
> only the requirements because I feel the solutions can be 
> similar or the
> same. I think it is useful for implementers.
> 
> Thanks,
> Rocky Wang
> 
> 
> > -----Original Message-----
> > From: Drage, Keith (Keith) [mailto:[email-masked]] 
> > Sent: 2006年3月27日 0:25
> > To: [email-masked]
> > Subject: [Sip] draft-cao-sip-response-identity-00.txt
> > 
> > (As chair)
> > 
> > At the face-to-face meeting at IETF #65 we discussed:
> > 
> > http://www.ietf.org/internet-drafts/draft-cao-sip-response-ide
> > ntity-00.txt
> > 
> > as a proposal for part of the solution to meeting the SIP 
> > milestone "Mechanism for Response Identity to IESG (PS)
> > 
> > A separate thread identifies another draft that forms part of 
> > this solution.
> > 
> > The face-to-face meeting reached no conclusion about whether 
> > this draft forms the basis for completing that milestone, or 
> > whether the problem cannot be resolved at all (or indeed that 
> > there is no support for a solution in this area) and 
> > therefore we should modify the existing milestone to remove 
> > response identity and leave only connected identity.
> > 
> > We would welcome proposals and comments to the list to 
> > resolve this issue one way or the other.
> > 
> > regards
> > 
> > Keith
> > 
> > Keith Drage
> > [email-masked]
> > 
> > _______________________________________________
> > 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: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 29 Mar 2006 09:22:43 -0600

> (as chair)
[...]
> We do not plan to make any decision about the documentation of
> draft-cao-sip-response-identity-00.txt until there is some consensus
> on the mechanisms proposed and support for moving forward. At the
> moment there have been no posts in favour or against achieving that
> consensus, and at the moment all we can assume is that there is no
> support for solving this problem at all.

Keith: Is it conceivable to break the milestone into two?  One provides
solution for knowing who I have connected with (connected-identity),
and the other provides the identity of the intermediary or endpoint
who issued provisional and non-2xx responses (could use response-
identity as a starting point).

I don't think there is much debate over connected-identity; the WG
agrees that this is the way forward on knowing authoritatively
who a UAC is connected to.  connected-identity, IIRC, only kicks in
when the UAS agrees to session establishment (i.e., a 200 OK is sent
out).  But what about user agents and intermediaries that issue non-2xx
responses?

Ostensibly, there could be some advantage in knowing that an
intermediary who issued a 3xx is not sending me on a wild
goose chase.  TLS could be one way to ascertain the identity of the
intermediary if I am connected directly (i.e., next hop) to the
responder.  But what about a chain of TLS proxies where the responding
proxy or UAS is a few hops downstream?  In that case, response-identity
allows the receiver to know who issued a final response.

So, does the WG see a need to provide a solution for response identity,
which could be defined as the identity of an intermediary issuing a
1xx response or a non-2xx response, or the identity of an endpoint
issuing a non-2xx response?  If so, then maybe the following can be
candidate proposals:

1) response-identity.
2) P-A-I applied to responses.
3) H-I header (I don't think this works since in H-I it is the
   UAC or the proxy that sends a request downstream that adds a
   H-I header.  A UAS echoes the H-I headers, but does not add
   them pre-emptively, AFAIK).
4) Others...?

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Wed, 29 Mar 2006 08:54:57 -0800

My take is that there is no agreement that there is a compelling reason

to do response identity. That's the main issue.

I agree that connected-identity on the other is non-controversial.

Vijay K. Gurbani wrote:

(as chair)

[...]

1) response-identity.

Thanks,

- vijay

---

From: Dean Willis <[email-masked]>
Date: Wed, 29 Mar 2006 12:04:49 -0600

> I agree that connected-identity on the other is non-controversial.

I propose that we amend the charter to show a midsummer deliverable  
for connected identity, and use the Elwell draft as a basis for this  
deliverable.

Then we add a later milestone to deliver a decision on whether we  
will be adding a new milestone for response identity.

How does that sound?

--
Dean

---

From: Shida Schubert <[email-masked]>
Date: Wed, 29 Mar 2006 10:54:51 -0800

I like the idea Dean is proposing.

They fundamentally solve different issues and I see no need
to merge the two and create unnecessary dependency.

Regards
Shida

Dean Willis wrote:
> Then we add a later milestone to deliver a decision on whether we will
> be adding a new milestone for response identity.
>
> How does that sound?
>
> -- 
> Dean
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 29 Mar 2006 18:07:00 -0800

> for connected identity, and use the Elwell draft as a basis for this
With my individual contributor hat on ...Sounds reasonable to me - we likely
want to get crisp about the difference between mid dialog identity and
changing the identity in a dialog forming request.

> will be adding a new milestone for response identity.
And I hope we have some discussion about what problem this solves before
adding it.