Subject: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis

From: Paul Kyzivat <[email-masked]>
Date: Sun, 05 Jun 2011 20:33:30 -0400

[as co-chair]

The current editor of draft-ietf-sipcore-rfc4244bis believes that the 
document has no remaining technical issues, and is ready for evaluation. 
Today, we are starting a two-week working group last call period. This 
last call period ends on Sunday, June 19.

The latest version of the document can be retrieved here:

http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis

Any comments on the document should be sent to the SIPCORE mailing list.

     Thanks,
     Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 9 Jun 2011 23:08:03 +0200

Hi,

Some comments, based on feedback I've got from collegues.

1. Usage of "rc" and "mp" in Contact header field (technical)

The document defines the "rc" and "mp" parameters also for the Contact header field. However, it is unclear when and how the parameters would be used in a Contact header field.

2. Tel to Sip transformation: ENUM (technical)

Section 5 talks about transformation from Tel to Sip, according section 19.6.1 of RFC 3261. However, the transformation can also be the result of an ENUM DNS lookup. So, maybe some text should be added, indicating that the transformation can be done based on local configuration (the hostpart of the new SIP-URI needs to be taken from somewhere), or based on an ENUM DNS lookup.

3. Tel to Sip transformation: History-Info (technical)

Related to the previous question, the text doesn't indicate whether the transformation from Tel to Sip should be recorded in an History-Info header field. The Request-URI is, after all, changed.

4. Home proxy (editorial)

The draft mentions "home proxy", but there is no reference or definition for it. I guess it should be "registrar", or something.

5. Out-of-dialog request (editorial)

Section 5 talks about "request not associated with an early or established dialog", while section 6.1 talks about "new or out-of-dialog request". In both cases the text refers to the request that can carry History-Info, so the wording should be consistance. For example "out-of-dialog requests or initial requests for a dialog".

6. Appearence (editorial)

Section 5 says in which message types History-Info "can appear". It would be better to say for which message types the document/specification defines the usage of History-Info.

7. Misc (editorial)

There are, throughout the document, some inconsistance between usage of "header" vs "header field", "this document" vs "this specification", the usage of capital letters for requests and SIP entity names etc, but I guess that can be taken care of by the authors without a list of every occurance here.

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 6. kesäkuuta 2011 3:34
To: SIPCORE (Session Initiation Protocol Core) WG
Cc: [email-masked]; SIPCORE Chairs; Robert Sparks
Subject: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis

[as co-chair]

The current editor of draft-ietf-sipcore-rfc4244bis believes that the document has no remaining technical issues, and is ready for evaluation. Today, we are starting a two-week working group last call period. This last call period ends on Sunday, June 19.

    Thanks,
    Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 15 Jun 2011 15:51:06 -0400

Following are editorial comments on 4244bis-05 in WGLC...

1) Page 8, section 5 first sentence: "REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc." get rid of the first "and".

2) Page 8, section 5 first bullet: "A mandatory parameter for...", change "parameter" to "field", since hi-targeted-to-uri is a header field not a parameter.

3) Page 13, Figure 1 caption isn't on the same page as the figure itself.  There's an extra whitespace line below the 'Proxy Cancels INVITE' double-arrow in the drawing which can be remove so that the caption fits on the same page as the figure.

4) Page 16, Section 9.3, end of section: "(e.g., 1.2 and 1.4 could but present..." should be "...could be present...".

-hadriel

---

From: Shida Schubert <[email-masked]>
Date: Thu, 16 Jun 2011 14:29:57 +0900

Hadriel;

 Thanks, we will reflect this on the next revision. 

 Regards
  Shida

---

From: Shida Schubert <[email-masked]>
Date: Fri, 17 Jun 2011 09:30:02 +0900

Hi Christer;

 Thanks for the comments and for reviewing the draft.

 My comments inline..

> The document defines the "rc" and "mp" parameters also for the Contact header field. However, it is unclear when and how the parameters would be used in a Contact header field.

 I think this is already described in the section 10.4. 

 "In the latter case, the specific header parameter field in the Contact
   header becomes the header field parameter that is used in the hi-
   target-param in the hi-entry when the request is retargeted."

> Section 5 talks about transformation from Tel to Sip, according section 19.6.1 of RFC 3261. However, the transformation can also be the result of an ENUM DNS lookup. So, maybe some text should be a…
 
 Are you talking about adding target-param based on ENUM lookup or 
simply recording the transformation/resolution in H-I? 

 Anyway, do you want to suggest some text as a co-author of the draft? :-)

> Related to the previous question, the text doesn't indicate whether the transformation from Tel to Sip should be recorded in an History-Info header field. The Request-URI is, after all, changed.

 I don't know if we need to add anything specific for this. The draft doesn't limit the 
behavior of the entity recording H-I to only record SIP-URI, it just says to record the 
R-URI. 

> The draft mentions "home proxy", but there is no reference or definition for it. I guess it should be "registrar", or something.

 I guess we can call it a "registrar" or at the first instance include a text used in 
RFC 3327. 

 REGISTRAR or a "home proxy" (a proxy serving as the terminal point for routing an address-of-record)

> Section 5 talks about "request not associated with an early or established dialog", while section 6.1 talks about "new or out-of-dialog request". In both cases the text refers to the request that c…

 I agree.

> Section 5 says in which message types History-Info "can appear". It would be better to say for which message types the document/specification defines the usage of History-Info.

 Sounds good. 

> There are, throughout the document, some inconsistance between usage of "header" vs "header field", "this document" vs "this specification", the usage of capital letters for requests and SIP entity…

 We thought we were pretty careful with this as John has pointed these out before. 

 We will go through the draft and make sure there is consistency with the wording. 

 Thanks
  Shida

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Jun 2011 09:25:47 +0200

Hi Shida, 
		 
>	   target-param in the hi-entry when the request is retargeted."

The text says what you use it for, but not how it was inserted in the Contact in the first place.

----------

>>Section 5 talks about transformation from Tel to Sip, according section 19.6.1 of RFC 3261. However, the transformation can also be the result of an ENUM DNS lookup. So, maybe some text should 
>>be added, indicating that the transformation can be done based on local configuration (the hostpart of the new SIP-URI needs to be taken from somewhere), or based on an ENUM DNS lookup.
>
>Are you talking about adding target-param based on ENUM lookup or simply recording the transformation/resolution in H-I? 

Both.

>Anyway, do you want to suggest some text as a co-author of the draft? :-)

Sure :) 

But, it is a little unclear to me what target-param (if any), I would include, so I would like that to get soreted out first.

----------
		  
>behavior of the entity recording H-I to only record SIP-URI, it just says to record the 

Based on the comments I get, the text seems to indicate that you shouldn't insert a Tel in a History-Info in the first place. Instead you should transform it to a SIP-URI before inserting it.

But, I can think of some text for that also, because it's related to the previous comments.

----------

>	 REGISTRAR or a "home proxy" (a proxy serving as the terminal point for routing an address-of-record)

I think it occurs only once, but as long as there is a definition (or a reference to a definition) I don't mind if it's used.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jun 2011 16:45:41 -0400

(as individual)

> Based on the comments I get, the text seems to indicate that you shouldn't insert a Tel in a History-Info in the first place. Instead you should transform it to a SIP-URI before inserting it.

I agree with Christer (!!!) that the transformation from tel: to sip: 
*is* a change, and if you care about H-I then this ought to be recorded.

(This is not just a superficial change in representation - it is a 
*semantic* change, because different processing rules apply to sip URIs 
that tel URIs.)

There isn't even a guarantee that a proxy will have a suitable way to 
re-represent a tel uri as a sip URI.

So I think this calls for some sort of explanation. I guess its lucky 
that if you do create H-I entries for this, that its the translated 
(sip) URI that gets the parameters added. So its at least *possible* to 
do this.

	Thanks,
	Paul

---

From: "Andrew Allen" <[email-masked]>
Date: Tue, 21 Jun 2011 10:35:39 -0500

Seems I missed the WGLC deadline by a day or so but here are the
comments from my review:

Section 5

"mp": The hi-targeted-to-URI represents a user other than the

 user associated with the Request-URI in the incoming request

  that was retargeted.

The term "user" here is confusing. Does it mean the human user (who
might have multiple AoRs/URIs which may or may not be known to the
retargeting proxy as AoRs/URIs that all map to the same human user)?
When retargeting is the proxy supposed to assess whether the new target
URI represents the same human user or not in order to determine whether
to include the "mp" parameter or not? I'm not sure what terminology
would be best but I think "user" is likely to cause confusion.

The above issue also reoccurs in section 7

Section 15

"Entities that have not implemented this specification MUST ignore these
parameters"?  We can't make any normative requirements on entities that
have not implemented this specification! Therefore the MUST should be
removed. I think you mean to state that according to RFC 3261 and RFC
4244 entities that are not compliant with this specification will ignore
these parameters.

There is a backward compatibility concern which I think should be
addressed. With 4244bis the URI in the Request-URI is now clearly to be
included in the History-Info when the Request-URI is replaced by the
Contact address. This was not the case in RFC 4244 where in many (if not
most) implementations rewriting the request-URI with the Contact was not
considered retargeting. Some existing UA implementations may have
assumed that the last History-Info entry cannot be their own Contact
Address but will always be their AoR. For example a UA may only look at
the next highest History-Info header field from the bottom most one in
order to determine whether the call arrived as a result of forwarding or
not from within their home domain and what the URI was that it was
forwarded from. Since outside the home domain of the UA up to now the
use of History-Info has not been deterministic some UAs may have only
looked at the last couple of History-Info header fields in order to
determine what happened to the request after it arrived within their
domain. In these kinds of scenarios having a proxy now add an additional
History-Info header field (for the rewriting of the Request-URI to the
Contact) in 4244bis may break the logic of such UAs. I am not saying we
shouldn't do this but I think some text about such possible problems
with existing implementations should be indicated in the backwards
compatibility section.

Section B.1
 
In this example, the Office and Home are not the

   same AOR as sip:[email-masked], but rather different AORs that have

   been configured as alternate addresses for Bob in the proxy.  In

   other words, Office and Bob are not bound through SIP Registration

with Bob's AOR.

The opportunity is missed to explain here that this means that the "rc"
parameter is not added. I think it would help to understand if that was
highlighted.

FLOW F1

INVITE sip:[email-masked]   should be INVITE sip:[email-masked]

FLOW F5

Request-URI for the ACK looks wrong to me shouldn't it be [email-masked]?

FLOW F6

The URI in the Request-URI and the URI in the bottom most History-Info
header field are not the same (R-URI = [email-masked] and H-I =
[email-masked]). These should be the same - suggest change R-URI to
[email-masked] so as to avoid need to change H-I in the other flows
and also since 192.0.2.3 is Alice's UA!!.

FLOW F13

Again Request-URI for the ACK looks wrong to me shouldn't it be
[email-masked]?

Examples in B.2 and B.3 do not have the same level of detail as in B.1
or RFC 4244.

Editorials

Last paragraph of 10.1 .2 "compenent" should be "component"

First and 2nd paragraph of 10.3 "add an hi-index"/"adds an hi-entry"
should be "a" not "an"

Regards

Andrew

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Sunday, June 05, 2011 7:34 PM
To: SIPCORE (Session Initiation Protocol Core) WG
Cc: [email-masked]; SIPCORE Chairs; Robert
Sparks
Subject: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis

[as co-chair]

    Thanks,
    Paul 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 21 Jun 2011 16:08:57 -0700

Privacy issue: There is no way to know that the next downstream proxy support the processing required by the privacy header. 

What's this for: The most concrete use is making sure a call arriving at a voice mail servers goes to the correct mailbox. However, the draft is woefully underspecified to be able to implement this from the draft. This draft specifies a bunch of data that can get dumped in a bag, but to allow interoperable implementation, it needs to say how one could use that data for some actually feature. 

As a coauthor of 4244, I agree this draft is better than 4244 but I don't think it is ready to publish.Given what we have learned about 4244 since it was published, I would support 4244 being changed to historic. 

Does it work? Consider text such as  

       Note, this would be
       the original AoR if all the entities involved support the
       History-info header field and there is absence of an "mp" header
       field parameter prior to the "rc" header field parameter in the
       hi-target-param in the History-info header field.  However, there
       is no guarantee that all entities will support History-Info, thus
       the hi-entry that matches the value of the "rc" parameter of the
       first hi-entry with an "rc" parameter in the hi-target-param
       within the domain associated with the target URI at the
       destination is more likely to be useful.

This amounts to you might some information you want at X but then again you might not. The whole draft is like this - it's pretty hard to imagine this will reliably work for nearly any purpose I can think of given the limitations of the draft. 

Backwards Compatibly - yes the syntax is backwards compatible but no effort has been put into consider what would happen if some elements in the network were doing 4244 and some where doing 4244bis.

Implementations: I'd like to know about implementations that were going to use this data. And by use, I don't mean write to the history header but instead ones that are going to read from it and use the information for some purpose. 

Does not meet requirements. As far as I can tell, the draft does not meet the requirements outline in section A.1 of the draft. 

On Jun 5, 2011, at 17:33 , Paul Kyzivat wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Shida Schubert <[email-masked]>
Date: Fri, 24 Jun 2011 21:16:37 +0900

Paul;

 Are you suggesting to include three hi-entries, 
whenever an entity retargeting the tel-URI 
logs it to H-I?

e.g. 

 History-Info : <tel:2222222>;index=1
 History-Info : <sip:{sip representation of tel URI}>; index=1.1; mp=1 
 History-Info : <sip:{retarget URI}>;index=1.2, rc=1.1 
  (based on the new semantics Hadriel suggested)

 In that case, how do you think the privacy of the tel URI 
should be handled? 

 Should the proxy apply the same privacy policy that it would 
apply to the SIP URI? 

 Regards
  Shida

On Jun 21, 2011, at 5:45 AM, Paul Kyzivat wrote:

> I agree with Christer (!!!) that the transformation from tel: to sip: *is* a change, and if you care about H-I then this ought to be recorded.
> 
> (This is not just a superficial change in representation - it is a *semantic* change, because different processing rules apply to sip URIs that tel URIs.)
> 
> There isn't even a guarantee that a proxy will have a suitable way to re-represent a tel uri as a sip URI.
> 
> So I think this calls for some sort of explanation. I guess its lucky that if you do create H-I entries for this, that its the translated (sip) URI that gets the parameters added. So its at least *possible* to do this.
> 
> 	Thanks,
> 	Paul

---

From: Shida Schubert <[email-masked]>
Date: Fri, 24 Jun 2011 21:17:42 +0900

Hi Christer;

 Comments inline.

> The text says what you use it for, but not how it was inserted in the Contact in the first place.

 Okay, I see your point. We will need to add a text with regards to this in the 
section describing the behavior of the redirection server. 

 I think the suggestion on the ML is to include the "mp" as far as I can tell. 

 I guess if the system doing the translation is certain that the target of 
tel URI and that of SIP URI is the same user then it can add "rc" according 
to the new semantics suggested by Hadriel.

---

From: Shida Schubert <[email-masked]>
Date: Fri, 24 Jun 2011 21:40:04 +0900

Hi Andrew;

 Thanks for your review. 

 My comments inline. 

On Jun 22, 2011, at 12:35 AM, Andrew Allen wrote:

> Seems I missed the WGLC deadline by a day or so but here are the comments from my review:
>  
> Section 5
>  
> The term “user” here is confusing. Does it mean the human user (who might have multiple AoRs/URIs which may or may not be known to the retargeting proxy as AoRs/URIs that all map to the same human user)? When retargeting is the proxy supposed to assess whether the new target URI represents the same human user or not in order to determine whether to include the “mp” parameter or not? I’m not sure what terminology would be best but I think “user” is likely to cause confusion.

 Your assumption is same as my understanding of this terminology as well. 

 It could be an individual or it could be a corporate entity.  

>  
> Section 15
> “Entities that have not implemented this specification MUST ignore these parameters”?  We can’t make any normative requirements on entities that have not implemented this specification! Therefore the MUST should be removed. I think you mean to state that according to RFC 3261 and RFC 4244 entities that are not compliant with this specification will ignore these parameters.

 Yes. 

>  
>  
> There is a backward compatibility concern which I think should be addressed. With 4244bis the URI in the Request-URI is now clearly to be included in the History-Info when the Request-URI is replaced by the Contact address. This was not the case in RFC 4244 where in many (if not most) implementations rewriting the request-URI with the Contact was not considered retargeting. Some existing UA implementations may have assumed that the last History-Info entry cannot be their own Contact Address but will always be their AoR. For example a UA may only look at the next highest History-Info header field from the bottom most one in order to determine whether the call arrived as a result of forwarding or not from within their home domain and what the URI was that it was forwarded from. Since outside the home domain of the UA up to now the use of History-Info has not been deterministic some UAs may have only looked at the last couple of History-Info header fields in order to determine what happened to the request after it arrived within their domain. In these kinds of scenarios having a proxy now add an additional History-Info header field (for the rewriting of the Request-URI to the Contact) in 4244bis may break the logic of such UAs. I am not saying we shouldn’t do this but I think some text about such possible problems with existing implementations should be indicated in the backwards compatibility section.

 The definition of retargeting in RFC4244 was not clear and it is definitely not 
defined in RFC3261, so I can understand why some may implement it the way 
you mentioned it. Although example in RFC4244 clearly inserts contact address 
as the History-Info. 

 Never the less, we will add some text with regards to this in the backward 
compatibility section.

> The opportunity is missed to explain here that this means that the “rc” parameter is not added. I think it would help to understand if that was highlighted.

 You are right, but Dale and Hadriel pointed the issue here with not marking 
hi-entry, so we are likely to change these texts as we are likely to change the 
semantics of "rc", from the looks of the discussion. 

 We will reflect the followings errors you found. 

 As for the details in call-flow B.2 and B.3, the idea is to focus only on 
H-I so it is easier for implementors to see what gets recorded. Do you prefer 
the extended version similar to B.1? 

 Regards
  Shida

> Request-URI for the ACK looks wrong to me shouldn’t it be [email-masked]?
>  
>  
> FLOW F6
>  
> The URI in the Request-URI and the URI in the bottom most History-Info header field are not the same (R-URI = [email-masked] and H-I =[email-masked]). These should be the same – suggest change R-URI [email-masked] so as to avoid need to change H-I in the other flows and also since 192.0.2.3 is Alice’s UA!!.
>  
>  
> FLOW F13
>  
> Again Request-URI for the ACK looks wrong to me shouldn’t it [email-masked]?
>  
>  
> Examples in B.2 and B.3 do not have the same level of detail as in B.1 or RFC 4244.
>  
>  
> Editorials
> Last paragraph of 10.1 .2 “compenent” should be “component”
> First and 2nd paragraph of 10.3 “add an hi-index”/”adds an hi-entry” should be “a” not “an”
>  
> Regards
> Andrew
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf OfPaul Kyzivat
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful._______________________________________________
> sipcore mailing list
> [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Jun 2011 09:33:05 -0400

On 6/24/2011 8:16 AM, Shida Schubert wrote:
>   History-Info :<tel:2222222>;index=1
>   History-Info :<sip:{sip representation of tel URI}>; index=1.1; mp=1
>   History-Info :<sip:{retarget URI}>;index=1.2, rc=1.1

That seems about right. (I'm not sure about the tags, just because I 
haven't been following that closely.)

>   In that case, how do you think the privacy of the tel URI

I guess you are asking because a privacy header can't be affixed to a 
tel uri?

If so, that suggests to me that handling privacy by embedding a privacy 
header into the URI was a mistake.

>   Should the proxy apply the same privacy policy that it would

Oh. Do you mean that when privacy is applied by hiding things belonging 
to the proxy's domain, how does it decide that this should be hidden too?

If it is hiding things because not hiding them would expose domain 
addresses, then there is no reason to hide the tel uri, since it doesn't 
expose a domain address.

NOTE: That is precisely why tel URIs are *not* equivalent to their sip 
"equivalent" URIs. The tel uri implies no domain - anyone wanting to 
call it is both free and obligated to seek out its own way of routing 
it. Calls to sip URIs are constrained to be routed based on the domain 
of the URI until reaching a server responsible for that domain.

For instance, if you have sip:[email-masked], and you have a 
device that has connectivity to both the pstn and internet, you are 
really obligated to route it to example.com. And if you currently only 
have pstn connectivity you ought not send it via the pstn.

But if you have tel:+12121234567, you are free to do whatever you want.

I know may devices will simply *assume* the sip uri is equivalent to a 
tel uri. But that isn't really proper. The device may have important 
features that can't work over a pstn connection.

(These comments are really from an individual, rather than chair, 
perspective.)

	Thanks,
	Paul

---

From: "Andrew Allen" <[email-masked]>
Date: Fri, 24 Jun 2011 09:31:55 -0500

Shida

Response below.

Andrew

From: Shida Schubert [mailto:[email-masked]] 
Sent: Friday, June 24, 2011 7:40 AM
To: Andrew Allen
Cc: SIPCORE Chairs; SIPCORE (Session Initiation Protocol Core) WG
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis

Hi Andrew;

 Thanks for your review. 

 My comments inline. 

Section 5

  that was retargeted.

 Your assumption is same as my understanding of this terminology as
well. 

[AA] So does the proxy that is doing the re-targeting need to have
definitive knowledge that the two URIs are for the same individual (or
corporate entity)? I am not convinced that a proxy will always know that
this is the case. Often call forwarding is done based on some kind of
user configuration. In some cases the user sets up the forwarding to
another URI of (owned by) the same human user but in other cases it is
not the same human user. For example I can choose to have all my calls
forwarded to some other person (such as wife, friend, or even a hotel
where I am staying). I don't know how a proxy can tell that the URI is
for the same human user or not in such circumstances.  I think this area
needs further explanation.

Section 15

 Yes. 

[AA] OK so this will be rephrased to remove the MUST?

 The definition of retargeting in RFC4244 was not clear and it is
definitely not 

defined in RFC3261, so I can understand why some may implement it the
way 

you mentioned it. Although example in RFC4244 clearly inserts contact
address 

as the History-Info. 

 Never the less, we will add some text with regards to this in the
backward 

compatibility section.

[AA] OK

Section B.1

with Bob's AOR.

 You are right, but Dale and Hadriel pointed the issue here with not
marking 

hi-entry, so we are likely to change these texts as we are likely to
change the 

 As for the details in call-flow B.2 and B.3, the idea is to focus only
on 

H-I so it is easier for implementors to see what gets recorded. Do you
prefer 

[AA] Yes I prefer the extended version as this is consistent with the
flows in most other SIP RFCs and also with RFC 4244. At the very least
the Request-URI, History-Info, and Contact headers need to be shown as
these all interact in a meaningful way in History Info.

 Regards

  Shida

 

FLOW F1

	 

	FLOW F5

	Request-URI for the ACK looks wrong to me shouldn't it be
[email-masked]?

	FLOW F6

	The URI in the Request-URI and the URI in the bottom most
History-Info header field are not the same (R-URI = [email-masked] and
H-I =[email-masked]). These should be the same - suggest change R-URI
[email-masked] so as to avoid need to change H-I in the other flows
and also since 192.0.2.3 is Alice's UA!!.

	FLOW F13

	Again Request-URI for the ACK looks wrong to me shouldn't it
[email-masked]?

	Examples in B.2 and B.3 do not have the same level of detail as
in B.1 or RFC 4244.

	Editorials

	First and 2nd paragraph of 10.3 "add an hi-index"/"adds an
hi-entry" should be "a" not "an"

	Regards

	Andrew

	From: [email-masked] [mailto:[email-masked]]
On Behalf OfPaul Kyzivat
	Sent: Sunday, June 05, 2011 7:34 PM
	To: SIPCORE (Session Initiation Protocol Core) WG
	Cc: [email-masked]; SIPCORE
Chairs; Robert Sparks
	Subject: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis

	[as co-chair]
	
	The current editor of draft-ietf-sipcore-rfc4244bis believes
that the document has no remaining technical issues, and is ready for
evaluation. Today, we are starting a two-week working group last call
period. This last call period ends on Sunday, June 19.

	
	Any comments on the document should be sent to the SIPCORE
mailing list.
	
	    Thanks,
	    Paul

--------------------------------------------------------------------- 
	This transmission (including any attachments) may contain
confidential information, privileged material (including material
protected by the solicitor-client or other applicable privileges), or
constitute non-public information. Any use of this information by anyone
other than the intended recipient is prohibited. If you have received
this transmission in error, please immediately reply to the sender and
delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended
recipients is not authorized and may be
unlawful._______________________________________________
	sipcore mailing list
	[email-masked]
	https://www.ietf.org/mailman/listinfo/sipcore

---

From: Shida Schubert <[email-masked]>
Date: Mon, 27 Jun 2011 11:06:18 +0900

Hi Andrew;

 My comments below. 

On Jun 24, 2011, at 11:31 PM, Andrew Allen wrote:

> [AA] So does the proxy that is doing the re-targeting need to have definitive knowledge that the two URIs are for the same individual (or corporate entity)? I am not convinced that a proxy will always know that this is the case. Often call forwarding is done based on some kind of user configuration. In some cases the user sets up the forwarding to another URI of (owned by) the same human user but in other cases it is not the same human user. For example I can choose to have all my calls forwarded to some other person (such as wife, friend, or even a hotel where I am staying). I don’t know how a proxy can tell that the URI is for the same human user or not in such circumstances.  I think this area needs further explanation.

 It assumes that Proxy has way to know whether this is the same user or not. 
 
 It could be that the user would indicate that the retargeting target is a same 
user when he/she configures the retargeting. And sometime proxy knows that 
it is a same user because it is configured as an alias to the original AoR etc.

 I agree some text needs to be added. 

> [AA] OK so this will be rephrased to remove the MUST?

 Yes. It makes no sense to mandate something from non-RFC4244bis compliant proxy. 

> [AA] Yes I prefer the extended version as this is consistent with the flows in most other SIP RFCs and also with RFC 4244. At the very least the Request-URI, History-Info, and Contact headers need to be shown as these all interact in a meaningful way in History Info.

 Okay, if that is what people want, we can change it to the extended version. 

 Regards
  Shida

---

From: Shida Schubert <[email-masked]>
Date: Mon, 27 Jun 2011 14:34:33 +0900

Hi Paul;

 My comments inline.

On Jun 24, 2011, at 10:33 PM, Paul Kyzivat wrote:

> That seems about right. (I'm not sure about the tags, just because I haven't been following that closely.)
> 
> I guess you are asking because a privacy header can't be affixed to a tel uri?
> 
> If so, that suggests to me that handling privacy by embedding a privacy header into the URI was a mistake.

 This wasn't what I was asking per se.  
 
 We can't express the desired way privacy is handled for tel URI due to the constrain 
you mentioned above, but what we can say in the draft is to suggest the use of Privacy 
header field instead of Privacy header embedded in the URI when tel URI is in the list 
of H-I which needs to be anonymized. 

 * Another question about anonymizing tel URI, AFAIK there is no guideline on how 
    one anonymizes tel URI? I guess if there is domain in "phone-context", we change that 
to "invalid.domain" or something. (May be in the security consideration?)

> Oh. Do you mean that when privacy is applied by hiding things belonging to the proxy's domain, how does it decide that this should be hidden too?

 Yes. 

> 
> If it is hiding things because not hiding them would expose domain addresses, then there is no reason to hide the tel uri, since it doesn't expose a domain address.
> 
> NOTE: That is precisely why tel URIs are *not* equivalent to their sip "equivalent" URIs. The tel uri implies no domain - anyone wanting to call it is both free and obligated to seek out its own way of routing it. Calls to sip URIs are constrained to be routed based on the domain of the URI until reaching a server responsible for that domain.
> 
> For instance, if you have sip:[email-masked], and you have a device that has connectivity to both the pstn and internet, you are really obligated to route it to example.com. And if you currently only have pstn connectivity you ought not send it via the pstn.
> 
> I know may devices will simply *assume* the sip uri is equivalent to a tel uri. But that isn't really proper. The device may have important features that can't work over a pstn connection.
> 
> (These comments are really from an individual, rather than chair, perspective.)

 So are you saying that privacy of tel URI shouldn't be a concern of a proxy that is 
handling the request, as long as the domain isn't exposed? 

 Regards
  Shida

---

From: Shida Schubert <[email-masked]>
Date: Mon, 27 Jun 2011 16:13:14 +0900

Hi Cullen;

 Thanks for your review and comments. 

 My comments inline.

> Privacy issue: There is no way to know that the next downstream proxy support the processing required by the privacy header. 

 That is generally true for any privacy mechanism based on 3323, this is not a problem limited to 4244/4244bis. 

 Most deployments I am aware of have these servers that handle the privacy. 

> What's this for: The most concrete use is making sure a call arriving at a voice mail servers goes to the correct mailbox. However, the draft is woefully underspecified to be able to implement this…

 We tried to cover these use-cases in section 3.3/3.4 of 4244bis-callflow draft.

 I am not sure, the example will satisfy you, but let me know what you think.

> This amounts to you might some information you want at X but then again you might not. The whole draft is like this - it's pretty hard to imagine this will reliably work for nearly any purpose I ca…

 I think it definitely has some uses and is valuable, even it is only supported within one domain 
which intend to use this. 

 Sure, there is a good chance that some information may get lost or may not exist in the 
first place when it crosses the domain due to the reason you mentioned above, but as long 
as all the entities within a domain who wants to use it, supports it, I believe it provides useful 
information.. 

> Backwards Compatibly - yes the syntax is backwards compatible but no effort has been put into consider what would happen if some elements in the network were doing 4244 and some where doing 4244bis.

 I am looking at this in more details right now, as I had some internal people form my company 
showing concern about this as well. I am hoping to add the summary of my findings in the next 
revision. 

> Does not meet requirements. As far as I can tell, the draft does not meet the requirements outline in section A.1 of the draft. 

 Do you mind being more specific if it is particular requirement you are talking about or 
are you saying all the requirements aren't satisfied by the mechanism?

 Thanks
  Shida