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

[<marianne.mohali at orange-ftgroup.com>]

Hi Keith,

Let's just talk about IARI. My idea was just to suggest a trail to improve History-Info. Before to create new things (headers or parameters), we should look what is available and reusable. If it is not conceivable to use IARI values in a History-Info header allowing a proxy server to indicate what has been done in term of service, could you please give a reason. 

Best Regards,
Marianne 

-----Message d'origine-----
De : DRAGE, Keith (Keith) [mailto:drage at alcatel-lucent.com] 
Envoyé : mardi 17 mars 2009 00:55
À : MOHALI Marianne RD-CORE-ISS; mary.barnes at nortel.com; audet at nortel.com
Cc : sip at ietf.org
Objet : RE: [Sip] 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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of 
> marianne.mohali at orange-ftgroup.com
> Sent: Monday, March 16, 2009 10:11 PM
> To: mary.barnes at nortel.com; audet at nortel.com
> Cc: sip at ietf.org
> 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 
> sip-implementors at cs.columbia.edu for questions on current sip Use 
> sipping at ietf.org for new developments on the application of sip
>