Re: I-D Action:draft-barnes-sip-rfc4244bis-00.txt

You wrote:

> ** To make the History-Info header usefull for applications 
> and services interactions, it could be interesting to be able 
> to include in the hi-target-to-uri IARI and ICSC values as 
> described in TS 24.229 (3GPP) wich ar coded as URN. An 
> example of an ICSI for a 3GPP defined IMS communication 
> service is: urn:urn-xxx:3gpp-service.ims.icsi.mmtel
> Do you think, this kind of enhancement for Histroy-Info 
> header could be added in the document ?

Question: What have these values to do with the history of a retargetting?

Keith 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of [email protected]
> Sent: Monday, March 16, 2009 10:11 PM
> To: [email protected]; [email protected]
> Cc: [email protected]
> Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt
> 
> 
> Hi Mary and François,
> 
> I have a suggestion and few comments on the document.
> 
> ** To make the History-Info header usefull for applications 
> and services interactions, it could be interesting to be able 
> to include in the hi-target-to-uri IARI and ICSC values as 
> described in TS 24.229 (3GPP) wich ar coded as URN. An 
> example of an ICSI for a 3GPP defined IMS communication 
> service is: urn:urn-xxx:3gpp-service.ims.icsi.mmtel
> Do you think, this kind of enhancement for Histroy-Info 
> header could be added in the document ?
> 
> ** Section 4.1: About Retarget (hi-target), it is indicated 
> "A retarget parameter is not added for a hi-entry when it is 
> first added in a History-
> Info header, but rather is added when the retargeting 
> actually occurs". It is indicated when the Retarget 
> indication should be added but it could be 	good to add an 
> information on where the parameter should be added 
> (associated to the retargeting hi-targeted-to-uri). This is 
> just to be clear on 	the History-Info header structure. 
> I have the same comment for the Reason header escaped in the 
> History-Info. About that, there is an inconsistency between 
> Reason header associated to 	the retargeting URI and 
> cause-param parameter (RFC4458) associated to the 
> retargeted-to URI. This should be corrected in RFC4458 but I 
> don't know if 	it is possible.
> 
> ** Section 4.5.1 and following: in the call flows there is a 
> "retarget" parmeter inserted in the second INVITE by Proxy1 
> when sending the request to Proxy2. In my understanding, it 
> should only be added (in the same place) by Proxy2 when 
> retargeting the request to Bob. Did I miss something ?
> 
> ** Privacy: I also think that it should be recommended in the 
> document to use the Privacy header with the value "history" 
> escaped in the hi-entries rather than directly in the INVITE 
> request.  
> 
> 
> Best Regards,
> Marianne
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use 
> [email protected] for questions on current sip 
> Use [email protected] for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip