Subject: Re: [dispatch] New Version Notification for draft-mohali-dispatch-cause-for-service-number-01.txt

From: <[email-masked]>
Date: Tue, 3 Feb 2015 14:39:53 +0000

Hi Paul,

Thank you for your feedback.

You said:

>The introduction now points out that the cause parameter can be used in the R-URI as well as in the History-Info header. But the solution only mentions the new cause parameter >value being used in H-I. Is there a reason why it can't be used in the the R-URI?
[MM] Actually there is no particular reason but having no usage example I focused the description on the usage we have in mind. In the same manner, RFC4458 was more focused on a usage in the Request-URI towards voicemail than in the History-Info for call forwarding service in general. If because it is a SIP/SIPS URI header (in general), you think I should add some text to give the same importance on its usage in a R-URI and/or in the History-Info header, I can do it. Is it your point?  If yes, I should add a warning that usage in the R-URI would have some limitation in regards with usage in the H-I header having more capabilities to give the information on why, how the incoming request arrives with privacy information...

>Also, in message F2 of the example, it *isn't* used in the R-URI of the retargeted request, even though it is included in the H-I entry containing that same URI. IIUC that URI in the H-I >ought to match what is in the R-URI.
[MM] No, the entry in the H-I is not mandatory to match exactly the one in the R-URI. The entry in the R-URI is a minimum base to create the corresponding H-I entry. You can have a simple R-URI and when it is added in the new H-I entry, the service can add some additional headers/parameters (eg. Reason, Privacy/ cause, target) in this entry or in the entry that retargeted the request (identified by the hi-target-param) before sending the request downstream. This example is exactly an example from RFC7131 with a usage of the cause-param only in the History-Info header. Depending on your response on the first point, I can add an example to show this new cause value in a R-URI. 

Best regards,
Marianne

-----Message d'origine-----
De : dispatch [mailto:[email-masked]] De la part de Paul Kyzivat
Envoyé : lundi 26 janvier 2015 20:31
À : [email-masked]
Objet : Re: [dispatch] New Version Notification for draft-mohali-dispatch-cause-for-service-number-01.txt

This makes more sense to me now than when I first read -00. (I don't know if it is because the text is better, or because of all the conversation in the meantime.)

I do have a comment:

The introduction now points out that the cause parameter can be used in the R-URI as well as in the History-Info header. But the solution only mentions the new cause parameter value being used in H-I. Is there a reason why it can't be used in the the R-URI?

Also, in message F2 of the example, it *isn't* used in the R-URI of the retargeted request, even though it is included in the H-I entry containing that same URI. IIUC that URI in the H-I ought to match what is in the R-URI.

	Thanks,
	Paul

On 1/26/15 8:58 AM, [email-masked] wrote:
> Hi all,
>
> I have submitted a new version of the draft
> http://tools.ietf.org/html/draft-mohali-dispatch-cause-for-service-num
> ber-01
> (see below).
>
> You can see the following changes:
>
> ----------------------------------------------------
>
> - Editorial comments from the mailing list have been taken into 
> account
>
> - More editorial changes have been done : remaining "header" into 
> "header field", "MUST" into "must",
>
> - After Jörgen's comment about usage of this new cause-param value in 
> the History-Info header field with the pre-requiste of the "mp"
> parameter or not I changed the way to defined this new value without 
> making a pre-requiste condition concerning the hi-target-param to be 
> used "rc" or "mp" in the History-Info header-field.
>
> - I also added more text on the fact that this document is only about 
> the cause URI parameter and not the cause header field parameter of 
> the Reason header. Indeed, the lack of clear distinction between those 
> 2 "cause" parameters brought many confusion in the past for the 
> History-Info header implementation.
>
> - After Dale's comment concerning the "IN" wording reference and 
> vocabulary, I added some explanatory text referring to Q1201 to give 
> more background to the reader on this old wording and the link with 
> the new vocabulary.
>
> - A complete example based on the Toll-Free example in RFC7131 has 
> been added.
>
> I hope this new version would be fine and I would like to have some 
> review and feedback on it.
>
> With the previous feedbacks and interests, I hope this document could 
> have a good progress in the working group and be presented at the next 
> meeting.
>
> Best Regards,
>
> Marianne
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] Envoyé 
> : mercredi 21 janvier 2015 13:03 À : MOHALI Marianne IMT/OLN; MOHALI 
> Marianne IMT/OLN Objet : New Version Notification for 
> draft-mohali-dispatch-cause-for-service-number-01.txt
>
> A new version of I-D, 
> draft-mohali-dispatch-cause-for-service-number-01.txt
>
> has been successfully submitted by Marianne Mohali and posted to the 
> IETF repository.
>
> Name:              draft-mohali-dispatch-cause-for-service-number
>
> Revision:          01
>
> Title:                 Session Initiation Protocol (SIP) Cause URI
> parameter for Service Number translation
>
> Document date:            2015-01-21
>
> Group:             Individual Submission
>
> Pages:             8
>
> URL:
> http://www.ietf.org/internet-drafts/draft-mohali-dispatch-cause-for-se
> rvice-number-01.txt
>
> Status:
> https://datatracker.ietf.org/doc/draft-mohali-dispatch-cause-for-servi
> ce-number/
>
> Htmlized:
> http://tools.ietf.org/html/draft-mohali-dispatch-cause-for-service-num
> ber-01
>
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-mohali-dispatch-cause-for-servi
> ce-number-01
>
> Abstract:
>
>     [RFC4458] defines a "cause" URI parameter as having predefined 
> values
>
>     for Redirecting reasons as a mapping from ITU-T Q.732.2-5 
> Redirecting
>
>     Reasons.  The "cause" URI parameter is to be used in SIP or SIPs URI.
>
>     In particular, it may appear in the History-Info header field
>
>     defined in [RFC7044] that must be added in retargeted requests.
>
>     This specification creates a new predefined value for cases when 
> the
>
>     retargeting is caused by a specific service action leading to a
>
>     called service access number translation.
>
>     This document updates [RFC4458].
>
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
>
> The IETF Secretariat
>
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Feb 2015 13:31:48 -0500

Hi Marianne,

> [MM] No, the entry in the H-I is not mandatory to match exactly the one in the R-URI. The entry in the R-URI is a minimum base to create the corresponding H-I entry. You can have a simple R-URI and…

I realize there is no *requirement* that the parameters be in the R-URI 
before that is moved into the H-I header. But it still seems to me to be 
the *intent* of H-I that the URIs included in it were ones that were 
used during the past history of the request. So IMO stuffing extra URI 
parameters in when putting the URI into H-I is an abuse or at least a hack.

In the case of F2, I can see no reason why the parameter would not be 
appropriate for use in the R-URI. I would expect the recipient would 
look there first, and then, if not found there, look back into the H-I 
for evidence of a cause earlier in the history of the request.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Fri, 6 Feb 2015 16:38:52 +0000

Hi Paul,

[MM2]

> De : Paul Kyzivat [mailto:[email-masked]]
> Envoyé : jeudi 5 février 2015 19:32
> À : MOHALI Marianne IMT/OLN; [email-masked]
> >> The introduction now points out that the cause parameter can be used in the R-
> URI as well as in the History-Info header. But the solution only mentions the new
> cause parameter >value being used in H-I. Is there a reason why it can't be used in
> the the R-URI?
> > [MM] Actually there is no particular reason but having no usage example I
> focused the description on the usage we have in mind. In the same manner,
> RFC4458 was more focused on a usage in the Request-URI towards voicemail than
> in the History-Info for call forwarding service in general. If because it is a SIP/SIPS
> URI header (in general), you think I should add some text to give the same
> importance on its usage in a R-URI and/or in the History-Info header, I can do it. Is
> it your point?  If yes, I should add a warning that usage in the R-URI would have
> some limitation in regards with usage in the H-I header having more capabilities to
> give the information on why, how the incoming request arrives with privacy
> information...
> >
> >> Also, in message F2 of the example, it *isn't* used in the R-URI of the
> retargeted request, even though it is included in the H-I entry containing that same
> URI. IIUC that URI in the H-I >ought to match what is in the R-URI.
> > [MM] No, the entry in the H-I is not mandatory to match exactly the one in the R-
> URI. The entry in the R-URI is a minimum base to create the corresponding H-I
> entry. You can have a simple R-URI and when it is added in the new H-I entry, the
> service can add some additional headers/parameters (eg. Reason, Privacy/ cause,
> target) in this entry or in the entry that retargeted the request (identified by the hi-
> target-param) before sending the request downstream. This example is exactly an
> example from RFC7131 with a usage of the cause-param only in the History-Info
> header. Depending on your response on the first point, I can add an example to
> show this new cause value in a R-URI.

> I realize there is no *requirement* that the parameters be in the R-URI before that is
> moved into the H-I header. But it still seems to me to be the *intent* of H-I that the
> URIs included in it were ones that were used during the past history of the request.
> So IMO stuffing extra URI parameters in when putting the URI into H-I is an abuse
> or at least a hack.
[MM2] IMO, they are 3 points that we have to distinct: 
1) There are headers that H-I RFC clearly mandate (with a *MUST*) to be added in the URI into the H-I only (Reason and Privacy headers).
2) There are SIP URI parameters that can be present in the R-URI anyway ('cause' and 'target' parameters included). 
3) There are H-I parameters that can be added only in the H-I header entries.
IIUC, your point concerns only 2). 
Indeed, I think RFC4458 was principally designed to use the 'cause' parameter in the R-URI (maybe because it was discussed in // of H-I when it was a draft) but it is not mentioned as a requirement and for several reasons it has been understood and interpreted as a parameter that can be present either only in the History-Info (as 3GPP use it) or in the R-URI and so automatically included in the H-I (as a copy of the R-URI). So usage in the History-Info is the minimum.
As an example, when privacy must be applied, RFC4458 states that the cause parameter must be removed from the R-URI whereas having it in the H-I enable to keep this forwarding reason but indicating the requested Privacy with the priv-value "history". So terminating entities that would rely on this parameter value, will go directly into the H-I to be sure to find it...and so why have it in the R-URI...
IMO, having this 'cause' in the R-URI + H-I or only H-I should be an implementor choice.
Anyway, I have no problem with adding an example with the 'cause' both in R-URI and H-I in the draft and adding an explicit sentence to state that this 'cause' param can be only in H-I or in the R-URI copied in H-I.

FYI, in the Voicemail example (section 3.6) of RFC7131 you can find the following call flow where there is no "cause" parameter in the R-URI but it is present in the corresponding hi-entry.

   F4 INVITE example.com -> Carol

   INVITE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK4522
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2
   Max-Forwards: 69
   From: Alice <sip:[email-masked]>;tag=kkaz-
   To: Bob <sip:[email-masked]>
   Supported: histinfo
   Call-ID: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D302>;\
                      index=1.1;rc=1
   History-Info: <sip:[email-masked];cause=480>;index=1.2;mp=1
   History-Info: <sip:[email-masked];cause=480>;index=1.2.1;rc=1.2
   Contact: Alice <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   [SDP Not Shown]

> In the case of F2, I can see no reason why the parameter would not be appropriate
> for use in the R-URI. I would expect the recipient would look there first, and then, if
> not found there, look back into the H-I for evidence of a cause earlier in the history
> of the request.
[MM2] Actually, many recipients directly go through H-I to have the cause information (avoiding the double check). In 3GPP specification it is described as to be added in the H-I with no specific requirement on its adding in the R-URI. At the end, my feeling is that the 'cause' parameter is optional in the R-URI.
However, if this new draft can be the opportunity to give some clarifications, I would be happy to add them in the text but I think it should not bring contradictory information with existing texts. 

BR,
Marianne
> > De : dispatch [mailto:[email-masked]] De la part de Paul
> > Kyzivat Envoyé : lundi 26 janvier 2015 20:31 À : [email-masked]
> > Objet : Re: [dispatch] New Version Notification for
> > This makes more sense to me now than when I first read -00. (I don't
> > know if it is because the text is better, or because of all the
> > conversation in the meantime.)
> >
> > I do have a comment:
> >
> > The introduction now points out that the cause parameter can be used in the R-
> URI as well as in the History-Info header. But the solution only mentions the new
> cause parameter value being used in H-I. Is there a reason why it can't be used in
> the the R-URI?
> >
> > Also, in message F2 of the example, it *isn't* used in the R-URI of the retargeted
> request, even though it is included in the H-I entry containing that same URI. IIUC
> that URI in the H-I ought to match what is in the R-URI.
> >
> > 	Thanks,
> > 	Paul
> >
> >
> >> have a good progress in the working group and be presented at the
> >> next meeting.
> >>
> >> Best Regards,
> >>
> >> Marianne
> >>
> _____________________________________________________________________
> >> _ ___________________________________________________
> >>
> >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces
> jointes. Les messages electroniques etant susceptibles d'alteration, Orange
> decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >>
> >> privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces
> jointes. Les messages electroniques etant susceptibles d'alteration, Orange
> decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Feb 2015 12:47:28 -0500

Hi Marianne,

Further discussion inline.

> 1) There are headers that H-I RFC clearly mandate (with a *MUST*) to be added in the URI into the H-I only (Reason and Privacy headers).

These are actually SIP Headers, encoded into the URI as sip uri *header* 
parameters. These actually cannot be included in an R-URI. (If they were 
in a URI that is to be used as the target for a request, they would be 
removed from the uri before it became the R-URI, and added to the 
request as sip headers.)

> 2) There are SIP URI parameters that can be present in the R-URI anyway ('cause' and 'target' parameters included).

These are examples of "regular" SIP URI parameters, that may be present 
in an R-URI. Their semantics is defined independent of where the URI 
containing them appears.

> 3) There are H-I parameters that can be added only in the H-I header entries.

Yes. These are not URI parameters at all, they are present in the H-I 
header field, outside of the URI.

> IIUC, your point concerns only 2).

Yes.

> Indeed, I think RFC4458 was principally designed to use the 'cause' parameter in the R-URI (maybe because it was discussed in // of H-I when it was a draft)

yes. Indeed IIRC it was proposed as a mechanism that would support 
voicemail servers *without* the need to use H-I.

> but it is not mentioned as a requirement and for several reasons it has been understood and interpreted as a parameter that can be present either only in the History-Info (as 3GPP use it)

My point is that this appears, to me, to be (choose one or more): 
inappropriate, a hack, an abuse, a bug.

> or in the R-URI and so automatically included in the H-I (as a copy of the R-URI). So usage in the History-Info is the minimum.

That is what I am discussing.

> As an example, when privacy must be applied, RFC4458 states that the cause parameter must be removed from the R-URI

That is interesting. I note that this statement in 4458 is 
non-normative. It seems to be trying to restate something implicit in 
RFC3323. But when I look at RFC3323 I see no such requirement. Nor can I 
think of any rationale for why these URI parameters would need to be 
removed as part of header privacy.

> whereas having it in the H-I enable to keep this forwarding reason but indicating the requested Privacy with the priv-value "history". So terminating entities that would rely on this parameter value, will go directly into the H-I to be sure to find it...and so why have it in the R-URI...

I recognize that this is a fuzzy area. I bring it up for broader discussion.

> Anyway, I have no problem with adding an example with the 'cause' both in R-URI and H-I in the draft and adding an explicit sentence to state that this 'cause' param can be only in H-I or in the R-…

That would be an improvement.

> [MM2] Actually, many recipients directly go through H-I to have the cause information (avoiding the double check).

And so they would fail to function properly when receiving a request 
where RFC4458 was in use but H-I wasn't. :-(

> In 3GPP specification it is described as to be added in the H-I with no specific requirement on its adding in the R-URI. At the end, my feeling is that the 'cause' parameter is optional in the R-URI.

Thanks.

	Paul

---

From: <[email-masked]>
Date: Thu, 12 Feb 2015 14:45:24 +0000

Hi Paul,

If I try to sum up:

In a general manner, we should consider that the 'cause' parameter should be present in both R-URI and in the H-I.
It can be present in the H-I as a copy of the R-URI or directly introduced in the H-I.
Indeed, for the following reasons, the cause parameter can be absent from the R-URI:
1- because it has been removed/not added for some privacy requirements of the diverting party (as mentioned RFC4458)
2- because the R-URI is a TelURI that cannot include the 'cause' parameter which is a SIP/SIPS URI parameter except by being changed into a SIP URI. (note that this is also true for the URI in the H-I that must be changed into a SIP URI to add the cause param but it is different to change the R-URI than a hi-entry)

Would it be fine if I add something like that in the draft and the 'cause' in the R-URI in the example section?

Of course the purpose of the draft in only to create a new value for the cause parameter but it can be also a good opportunity to fix ambiguities created in the past.

Additional answers inline [MM3]

Marianne

> Envoyé : vendredi 6 février 2015 18:47
> >> De : Paul Kyzivat [mailto:[email-masked]] Envoyé : jeudi 5
> >> février 2015 19:32 À : MOHALI Marianne IMT/OLN; [email-masked]
> >> draft-mohali-dispatch-cause-for- service-number-01.txt
> >>
> >> Hi Marianne,
> >>
> >> URI as well as in the History-Info header. But the solution only
> >> mentions the new cause parameter >value being used in H-I. Is there a
> >> reason why it can't be used in the the R-URI?
> >> RFC4458 was more focused on a usage in the Request-URI towards
> >> voicemail than in the History-Info for call forwarding service in
> >> general. If because it is a SIP/SIPS URI header (in general), you
> >> think I should add some text to give the same importance on its usage
> >> in a R-URI and/or in the History-Info header, I can do it. Is it your
> >> point?  If yes, I should add a warning that usage in the R-URI would
> >> have some limitation in regards with usage in the H-I header having
> >> more capabilities to give the information on why, how the incoming request
> arrives with privacy information...
> >>>
> >> retargeted request, even though it is included in the H-I entry
> >> containing that same URI. IIUC that URI in the H-I >ought to match what is in the
> R-URI.
> >> URI. The entry in the R-URI is a minimum base to create the
> >> corresponding H-I entry. You can have a simple R-URI and when it is
> >> added in the new H-I entry, the service can add some additional
> >> headers/parameters (eg. Reason, Privacy/ cause,
> >> target-param) before sending the request downstream. This example is
> >> exactly an example from RFC7131 with a usage of the cause-param only
> >> in the History-Info header. Depending on your response on the first
> >> point, I can add an example to show this new cause value in a R-URI.
> >
> >> I realize there is no *requirement* that the parameters be in the
> >> R-URI before that is moved into the H-I header. But it still seems to
> >> me to be the *intent* of H-I that the URIs included in it were ones that were used
> during the past history of the request.
> >> So IMO stuffing extra URI parameters in when putting the URI into H-I
> >> is an abuse or at least a hack.
> > 1) There are headers that H-I RFC clearly mandate (with a *MUST*) to be added in
> the URI into the H-I only (Reason and Privacy headers).
> 
> parameters. These actually cannot be included in an R-URI. (If they were in a URI
> that is to be used as the target for a request, they would be removed from the uri
> before it became the R-URI, and added to the request as sip headers.)
> 
[MM3] yes

> These are examples of "regular" SIP URI parameters, that may be present in an R-
> URI. Their semantics is defined independent of where the URI containing them
> appears.
> 
[MM3] Exact with the exception that they are only for SIP/SIPS URIs and not for TelURI and the R-URI can be a TelURI.

> Yes. These are not URI parameters at all, they are present in the H-I header field,
> outside of the URI.
> 
> > Indeed, I think RFC4458 was principally designed to use the 'cause'
> > parameter in the R-URI (maybe because it was discussed in // of H-I
> > when it was a draft)
> 
> yes. Indeed IIRC it was proposed as a mechanism that would support voicemail
> servers *without* the need to use H-I.
> 
> > but it is not mentioned as a requirement and for several reasons it
> > has been understood and interpreted as a parameter that can be present
> > either only in the History-Info (as 3GPP use it)
> 
> > or in the R-URI and so automatically included in the H-I (as a copy of the R-URI).
> So usage in the History-Info is the minimum.
> 
> > As an example, when privacy must be applied, RFC4458 states that the
> > cause parameter must be removed from the R-URI
> 
> That is interesting. I note that this statement in 4458 is non-normative. It seems to
> be trying to restate something implicit in RFC3323. But when I look at RFC3323 I
> see no such requirement. Nor can I think of any rationale for why these URI
> parameters would need to be removed as part of header privacy.
>
[MM3] Correct me if I'm wrong but RFC4458 is informational and as such it cannot contain normative statement. no?
IMO, the rational about the cause removal is not the first point for the privacy consideration but it is more about the target parameter which explicitly reveal the diverting user identity. 
 
> > whereas having it in the H-I enable to keep this forwarding reason but indicating
> the requested Privacy with the priv-value "history". So terminating entities that
> would rely on this parameter value, will go directly into the H-I to be sure to find
> it...and so why have it in the R-URI...
> > Anyway, I have no problem with adding an example with the 'cause' both in R-
> URI and H-I in the draft and adding an explicit sentence to state that this 'cause'
> param can be only in H-I or in the R-URI copied in H-I.
> 
[MM3] fine for me.
> 
> > FYI, in the Voicemail example (section 3.6) of RFC7131 you can find the
> following call flow where there is no "cause" parameter in the R-URI but it is present
> in the corresponding hi-entry.
> >
> >> look there first, and then, if not found there, look back into the
> >> H-I for evidence of a cause earlier in the history of the request.
> And so they would fail to function properly when receiving a request where
> RFC4458 was in use but H-I wasn't. :-(
> 
> > In 3GPP specification it is described as to be added in the H-I with no specific
> requirement on its adding in the R-URI. At the end, my feeling is that the 'cause'
> parameter is optional in the R-URI.
> > However, if this new draft can be the opportunity to give some clarifications, I
> would be happy to add them in the text but I think it should not bring contradictory
> information with existing texts.
> 
> Thanks.
> 
> 	Paul
> 
> > BR,
> > Marianne
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >>> Best regards,
> >>> Marianne
> >>>
> >> URI as well as in the History-Info header. But the solution only
> >> mentions the new cause parameter value being used in H-I. Is there a
> >> reason why it can't be used in the the R-URI?
> >>>
> >> request, even though it is included in the H-I entry containing that
> >> same URI. IIUC that URI in the H-I ought to match what is in the R-URI.
> >>>
> >>> 	Thanks,
> >>> 	Paul
> >>>
> >>>
> >>>> http://tools.ietf.org/html/draft-mohali-dispatch-cause-for-service-
> >>>> nu
> >>>> m
> >>>> ber-01
> >>>> (see below).
> >>>>
> >>>> - After Jörgen's comment about usage of this new cause-param value
> >>>> in the History-Info header field with the pre-requiste of the "mp"
> >>>> parameter or not I changed the way to defined this new value
> >>>> without making a pre-requiste condition concerning the
> >>>> hi-target-param to be used "rc" or "mp" in the History-Info header-field.
> >>>>
> >>>> - I also added more text on the fact that this document is only
> >>>> about the cause URI parameter and not the cause header field
> >>>> parameter of the Reason header. Indeed, the lack of clear
> >>>> distinction between those
> >>>> vocabulary, I added some explanatory text referring to Q1201 to
> >>>> give more background to the reader on this old wording and the link
> >>>> with the new vocabulary.
> >>>>
> >>>> With the previous feedbacks and interests, I hope this document
> >>>> could have a good progress in the working group and be presented at
> >>>> the next meeting.
> >>>>
> >>>> Best Regards,
> >>>>
> >>>> Marianne
> >>>>
> >>>> : mercredi 21 janvier 2015 13:03 À : MOHALI Marianne IMT/OLN;
> >>>> MOHALI Marianne IMT/OLN Objet : New Version Notification for
> >>>> has been successfully submitted by Marianne Mohali and posted to
> >>>> the IETF repository.
> >>>>
> >>>> http://www.ietf.org/internet-drafts/draft-mohali-dispatch-cause-for
> >>>> -s
> >>>> e
> >>>> rvice-number-01.txt
> >>>>
> >>>> Status:
> >>>> https://datatracker.ietf.org/doc/draft-mohali-dispatch-cause-for-se
> >>>> rv
> >>>> i
> >>>> ce-number/
> >>>>
> >>>> Htmlized:
> >>>> http://tools.ietf.org/html/draft-mohali-dispatch-cause-for-service-
> >>>> nu
> >>>> m
> >>>> ber-01
> >>>>
> >>>> Diff:
> >>>> http://www.ietf.org/rfcdiff?url2=draft-mohali-dispatch-cause-for-se
> >>>> rv
> >>>> i
> >>>> ce-number-01
> >>>>
> >>>> Abstract:
> >>>>
> >>>>       [RFC4458] defines a "cause" URI parameter as having
> >>>> predefined values
> >>>>
> >>>>       This specification creates a new predefined value for cases
> >>>> when the
> >>>>
> >>>> confidentielles ou privilegiees et ne doivent donc pas etre
> >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
> >>>> ce message par erreur, veuillez le signaler a l'expediteur et le
> >>>> detruire ainsi que les pieces
> >> jointes. Les messages electroniques etant susceptibles d'alteration,
> >>>> If you have received this email in error, please notify the sender
> >>>> and delete this
> >> message and its attachments.
> >>>> As emails may be altered, Orange is not liable for messages that
> >>>> have been
> >> modified, changed or falsified.
> >>>> Thank you.
> >>>>
> >>>>
> >>>>
> >> _
> >>> confidentielles ou privilegiees et ne doivent donc pas etre
> >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
> >>> ce message par erreur, veuillez le signaler a l'expediteur et le
> >>> detruire ainsi que les pieces
> >> jointes. Les messages electroniques etant susceptibles d'alteration,
> >>> If you have received this email in error, please notify the sender
> >>> and delete this
> >> message and its attachments.
> >>> As emails may be altered, Orange is not liable for messages that
> >>> have been
> >> modified, changed or falsified.
> >>> Thank you.
> >>>
> >>>
> >
> >
> >