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

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:dispatch-bounces@ietf.org] *On Behalf Of *Christer
Holmberg
*Sent:* Wednesday, March 23, 2016 2:46 AM
*To:* Paul Kyzivat; dispatch@ietf.org
*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".

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 <pkyzivat@alum.mit.edu>
*Sent: *‎22/‎03/‎2016 20:31
*To: *dispatch@ietf.org
*Subject: *Re: [dispatch] New draft
draft-mohali-dispatch-originating-cdiv-parameter-00.txt

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, marianne.mohali@orange.com 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.
>
> 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.
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch