Subject: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt

From: <[email-masked]>
Date: Mon, 21 Mar 2016 19:24:10 +0000

Hello,

Please find hereafter a new Internet-Draft  "P-Served-User Header Field Parameter for Originating CDIV session case in Session Initiation Protocol (SIP)".
The purpose of the draft is to register a new SIP parameter for the P-Served-User header field defined as per RFC5502.

Abstract:
   This specification defines a new Session Initiation Protocol (SIP) P-
   Served-User header field parameter, "orig-cdiv-param", which defines
   the session case used by a proxy when handling an originating session
   after Call Diversion (CDIV) services has been invoked for the served
   user.  The P-Served-User header field is defined in [RFC5502].  The
   P-Served-User header field conveys the identity of the served user
   and the session case that applies to this particular communication
   session and application invocation.
   This document updates [RFC5502] in order to add the originating after
   CDIV session case.

The draft can be found in :
URL:            https://www.ietf.org/internet-drafts/draft-mohali-dispatch-originating-cdiv-parameter-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mohali-dispatch-originating-cdiv-parameter/
Htmlized:       https://tools.ietf.org/html/draft-mohali-dispatch-originating-cdiv-parameter-00

Best Regards,
Marianne Mohali

_________________________________________________________________________________________________________________________

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: Tue, 22 Mar 2016 14:31:16 -0400

Marianne,

Thank you. This draft is a huge improvement over the prior proposal for 
this purpose!

I don't have a problem with this approach. The draft seems in reasonable 
shape. (I didn't read it for nits, as doing that seems premature.)

One thing I noticed, which is really an issue with rfc5502:

The P-Served-User header field doesn't seem to have the usual provision 
of headers like this for comma-separated repetition. And there is no 
mention pro or con regarding whether this header field can be repeated. 
Since it can already have both orig and term options, that presumably 
can coexist, I guess it can be repeated, but not using comma. Is that 
how it is being used in practice?

It would be wise to clarify the ways in which this header field may be 
repeated. (E.g., every usage must have a distinct value of 
sessioncase-param.) And if multiple values separated by comma are being 
used in practice then the syntax ought to be corrected to allow that.

	Thanks,
	Paul

On 3/21/16 3:24 PM, [email-masked] wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 Mar 2016 06:45:59 +0000

Hi,

As far as I remember, in SIP all "repeatable" header fields shall also be "comma separabable".

I can't think of a header field where that would not be the case.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎22/‎03/‎2016 20:31
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt

Marianne,

        Thanks,
        Paul

---

From: Brett Tate <[email-masked]>
Date: Wed, 23 Mar 2016 07:07:09 -0400

Hi,

RFC 3261 section 7.3.1 indicates the rule and the exceptions.

“  Multiple header field rows with the same field-name MAY be present in

   a message if and only if the entire field-value for that header field

   is defined as a comma-separated list (that is, if follows the grammar

   defined in Section 7.3).  It MUST be possible to combine the multiple

   header field rows into one "field-name: field-value" pair, without

   changing the semantics of the message, by appending each subsequent

   field-value to the first, each separated by a comma.  The exceptions

   to this rule are the WWW-Authenticate, Authorization, Proxy-

   Authenticate, and Proxy-Authorization header fields.  Multiple header

   field rows with these names MAY be present in a message, but since

   their grammar does not follow the general form listed in Section 7.3,

   they MUST NOT be combined into a single header field row.”

*From:* dispatch [mailto:[email-masked]] *On Behalf Of *Christer
Holmberg
*Sent:* Wednesday, March 23, 2016 2:46 AM
*To:* Paul Kyzivat; [email-masked]
*Subject:* Re: [dispatch] New draft
draft-mohali-dispatch-originating-cdiv-parameter-00.txt

Hi,

As far as I remember, in SIP all "repeatable" header fields shall also be
"comma separabable".

Regards,

Christer

Sent from my Windows Phone
------------------------------

*From: *Paul Kyzivat <[email-masked]>
*Sent: *‎22/‎03/‎2016 20:31
*To: [email-masked]
*Subject: *Re: [dispatch] New draft
draft-mohali-dispatch-originating-cdiv-parameter-00.txt

Marianne,

        Thanks,
        Paul

On 3/21/16 3:24 PM, [email-masked] wrote:
> Hello,
>
> Please find hereafter a new Internet-Draft  "P-Served-User Header Field
Parameter for Originating CDIV session case in Session Initiation Protocol
(SIP)".
> The purpose of the draft is to register a new SIP parameter for the
P-Served-User header field defined as per RFC5502.
> URL:
https://www.ietf.org/internet-drafts/draft-mohali-dispatch-originating-cdiv-parameter-00.txt
> Status:
https://datatracker.ietf.org/doc/draft-mohali-dispatch-originating-cdiv-parameter/
> Htmlized:
https://tools.ietf.org/html/draft-mohali-dispatch-originating-cdiv-parameter-00
>
> 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,
> This message and its attachments may contain confidential or privileged
information that may be protected by law;

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Mar 2016 10:22:59 -0400

> I can't think of a header field where that would not be the case.

The header fields with that property have syntax to match.

The syntax in 5502 doesn't support that for this header field. If that 
was then intent then the syntax should be revised.

	Thanks,
	Paul

> ------------------------------------------------------------------------
> From: Paul Kyzivat <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> Subject: Re: [dispatch] New draft
>> URL:https://www.ietf.org/internet-drafts/draft-mohali-dispatch-originating-cdiv-parameter-00.txt
>> Status:https://datatracker.ietf.org/doc/draft-mohali-dispatch-originating-cdiv-parameter/
>> Htmlized:https://tools.ietf.org/html/draft-mohali-dispatch-originating-cdiv-parameter-00
>>
>> Best Regards,
>> Marianne Mohali
>>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 Mar 2016 15:04:42 +0000

Hi,

> The syntax in 5502 doesn't support that for this header field. If that was then intent then the syntax > should be revised.

Correct.

Regards,

Christer

> Thank you. This draft is a huge improvement over the prior proposal 
> for this purpose!
>
> I don't have a problem with this approach. The draft seems in 
> reasonable shape. (I didn't read it for nits, as doing that seems 
> premature.)
>
> The P-Served-User header field doesn't seem to have the usual 
> provision of headers like this for comma-separated repetition. And 
> there is no mention pro or con regarding whether this header field can be repeated.
> sessioncase-param.) And if multiple values separated by comma are 
> being used in practice then the syntax ought to be corrected to allow that.
>
>          Thanks,
>          Paul
>
>> _____________________________________________________________________
>> ____________________________________________________
>>
>> 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.

---

From: Robert Sparks <[email-masked]>
Date: Fri, 25 Mar 2016 17:30:07 -0500

> As far as I remember, in SIP all "repeatable" header fields shall also 
It would be good to look at the bottom of page 30 of RFC3261 to inform 
this conversation.
In particular:
" It MUST be possible to combine the multiple
    header field rows into one "field-name: field-value" pair, without
    changing the semantics of the message, by appending each subsequent
    field-value to the first, each separated by a comma."

> I can't think of a header field where that would not be the case.
"The exceptions to this rule are the WWW-Authenticate, Authorization, 
Proxy- Authenticate, and Proxy-Authorization header fields."
> > Please find hereafter a new Internet-Draft "P-Served-User Header 
> Field Parameter for Originating CDIV session case in Session 
> Initiation Protocol (SIP)".
> > 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,
> privileged information that may be protected by law;
> > 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: <[email-masked]>
Date: Tue, 29 Mar 2016 06:34:36 +0000

Hi Paul,

Thank you for your feedback!

From my view, I was thinking that only one P-Served-User (with one session-case) can be present in a request at the same time.
Eg: A calls B which has a CDIV service. The incoming request to B will contain a P-Served-User with the session case 'term', then the AS triggering CDIV service will remove this entry containing the 'term' session case and replace it by a P-Served-User (with the same user) but the 'orig-cdiv' session case to indicate to the S-CSCF which iFC apply.

For that, I'm not sure we can have the P-Served-User repeated. How does the receiving entity will know what to do and for "who" if there are several choices?

BR,
Marianne

-----Message d'origine-----
De : dispatch [mailto:[email-masked]] De la part de Paul Kyzivat
Envoyé : mercredi 23 mars 2016 15:23
À : Christer Holmberg; [email-masked]
Objet : Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt

The syntax in 5502 doesn't support that for this header field. If that was then intent then the syntax should be revised.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Mar 2016 11:09:04 -0400

> For that, I'm not sure we can have the P-Served-User repeated. How does the receiving entity will know what to do and for "who" if there are several choices?

I'm just going by what I read - I don't otherwise know how you imagine 
it being used. If you think there can be only one instance of this 
header field at a time, and it might be revised/replaced/removed along 
the way, then it would be good to say that.

I was thinking that you might have multiple instances with different 
modifiers, indicating different *kinds* of served users.

	Thanks,
	Paul