Subject: [Sip] Updated connected-identity draft

From: "Elwell, John" <[email-masked]>
Date: Mon, 06 Mar 2006 10:50:05 +0000

draft-elwell-sip-connected-identity is now available:
http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity-01.t
xt
<http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity-01.
txt> 

Compared with the 00 version, this has changed considerably and is intended
to reflect decisions made in Vancouver. It exploits the ability to change
the From URI during a dialog, so that requests in the reverse direction can
place the source URI in the From header field and the Identity header can be
used to provide authentication, rather having to introduce new headers.
Comments would be appreciated. I would like to get this adopted as a SIP WG
item in Dallas.

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

---

From: Frank Derks <[email-masked]>
Date: Thu, 9 Mar 2006 10:23:07 +0100

John,

I had a look at the new draft and would like to make a few comments.

- In section 3 you provide an example of a transfer ("Parties 
involved...").
  Possibly, I am missing something, but I don't see how the example
  relates to this draft. 

- It might be a good idea to move section 4 to section 9, because it
  relates to security aspects.

- In section 5 you write about the "response identity problem". Are
  you referring to the fact that it is difficult to authenticate 
  identities in responses?

- The "OPEN ISSUE" in section 5, re-states something that was said
  earlier in the same section ("Note that it might also ..."). It 
  would seem that this earlier statement removes the need to keep
  this issue open.

- In 6.1/6.2/6.3 there are several occasions in which a "MUST" might 
  be more appropriate than a "SHOULD" and a "SHOULD" than a "MAY": 

    6.1:
    "... the UPDATE method [4] SHOULD ..." -> "MUST"?
    "... the re-INVITE method SHOULD ..." -> "MUST"?
    "... the UA MAY ..." -> "SHOULD"?

    6.2:
    "... on that dialog, the UA MAY..." -> "SHOULD"?

    6.3:
    "... on that dialog, the UA MAY ..." -> SHOULD?

- In 6.1 you raise an appropriate open issue. My two cents: for 
  consistency's sake (see also the 4th paragraph in 6.2), I would
  say that this is indeed a good idea. 

  In the same piece of text you say something about the SDP that
  might have to be included in the UPDATE. When this is indeed 
  required, it also becomes necessary to say something about what
  this SDP has to look like. RFC3311 is not at all clear about
  the scope of UPDATE. UPDATE is said to be a "target refresh
  request", but the definition of this is rather loose: "a 
  request that can modify the remote target of the dialog". What
  does "modify" mean in this context?

Cheers,

Frank

"Elwell, John" <[email-masked]> 
2006-03-06 11:50 AM

To
[email-masked]
cc

Subject
[Sip] Updated connected-identity draft
Classification

draft-elwell-sip-connected-identity is now available: 
http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity-01.txt 

Compared with the 00 version, this has changed considerably and is 
intended to reflect decisions made in Vancouver. It exploits the ability 
to change the From URI during a dialog, so that requests in the reverse 
direction can place the source URI in the From header field and the 
Identity header can be used to provide authentication, rather having to 
introduce new headers. Comments would be appreciated. I would like to get 
this adopted as a SIP WG item in Dallas.
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

---

From: Hans Persson <[email-masked]>
Date: Fri, 10 Mar 2006 10:50:49 +0100

>   be more appropriate than a "SHOULD" and a "SHOULD" than a "MAY": 
[...]
>     "... on that dialog, the UA MAY ..." -> SHOULD?

I agree. If we don't really care about alerting the end user of the
change in identity of the party in the other end, we do we even bother
writing this spec in the first place?

Section 6.3 looks pretty general at first, talking about "a UA". In
section 5 it says "A request in either direction after answer can
indicate a change of party.", and this section (6.3) is about
established calls. However, it only talks about discrepancies between
the To header of the received request and the identity of the UA.
Shouldn't it also talk about the From header of the sent request and the
identity of the UA (the *other* UA)?

Nits:

Section 2, first line: The [1] reference to SIP is missing whitespace on
both sides.

Section 7.1, first paragraph: "conveys it identity" -> "conveys its
identity". "Identity and Identity-Info header field" -> "Identity and
Identity-Info header fields".

Both the example in 7.1 and the one in 7.2 are inconsistent about
putting a space between the message name and the message number.
Sometimes it is "INVITE(1)", sometimes "INVITE (1)". I would prefer
having the space in all instances.

Example 7.1: The messages "200(3)" and "200(4)" in the diagram should be
listed as "200 (4)" and "200 (3)" since they are traveling from the
right to the left.
The "ACK (6)" message would be retargeted to "ACK
sip:[email-masked]" like the INVITE, wouldn't it?

Example 7.2: The left one of the "200 (3)" labels should really be "200
(4)". The re-INVITEs are labeled 11,12 but should be labeled 12,11. The
same goes for the associated ACKs (15,16) which should be 16,15.

Hans

-- 
Hans Persson <[email-masked]>    Ingate - Firewalls with SIP & NAT
Ingate Systems AB  +46 13 210877   http://www.ingate.com/

Private: <[email-masked]>  http://www.lysator.liu.se/~unicorn/

---

From: Frank Derks <[email-masked]>
Date: Fri, 10 Mar 2006 11:24:06 +0100

Hi Hans,

> writing this spec in the first place?

I wouldn't put it that strongly, but this was certainly one of my 
considerations for making some of the requirements stronger than "MAY".

There are however situations in which informing the "real user" is not
the goal, but informing an application that acts as the user is;-)

Cheers,

Frank