Subject: Re: [dispatch] WG review of draft-mohali-dispatch-cause-for-service-number

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 May 2015 10:26:26 -0400

On 4/1/15 1:27 PM, Mary Barnes wrote:
> Hi all,
>
> As posted on the mailing list prior to IETF-92 and as mentioned during
> the DISPATCH WG session last week, the proposal is to progress this
> document as AD sponsored:
> http://datatracker.ietf.org/doc/draft-mohali-dispatch-cause-for-service-number
>
> Please review and provide any comments.  In addition, please indicate
> whether or not you support progression of the document as AD sponsored
> no later than Wednesday, April 15, 2015.

I made my comments back in jan/feb: 
<http://mailarchive.ietf.org/arch/msg/dispatch/DODROdsfVcGNgY04itQn7CFzt0c>

I remain dubious about the defining a parameter for the Reason header 
field that is not intended to ever appear in a Reason header field of 
any sip request - instead only to appear embedded in a URI when that URI 
is placed in a H-I header. This is a hack.

	Thanks,
	Paul

> Regards,
> Mary Barnes
> DISPATCH WG co-chair
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: <[email-masked]>
Date: Mon, 4 May 2015 09:26:23 +0000

Dear Paul,

You say:
>I remain dubious about the defining a parameter for the Reason header field that is not intended to ever appear in a Reason header field of any sip request - instead only to appear embedded in a URI when that URI is placed in a H-I header. This is a hack.

But 
-1st, this draft it is not at all about a parameter for the Reason header field. It is a new value for the "cause" parameter which is a SIP/SIPS URI parameter.
-2nd, it is not required to be embedded in a URI only when that URI is placed in a H-I header (see following extract): 
	The "cause" URI parameter may be used either in the History-Info header
	field and/or in the Request-URI to indicate the service that the User
	Agent Server (UAS) receiving the message should perform.

However, to make it more explicit I'm going to update the draft to add this cause in the R-URI of the example in section 4 and improve the sentence above-mentioned.

Best regards,
Marianne

-----Message d'origine-----
De : dispatch [mailto:[email-masked]] De la part de Paul Kyzivat
Envoyé : vendredi 1 mai 2015 16:26
À : [email-masked]
Objet : Re: [dispatch] WG review of draft-mohali-dispatch-cause-for-service-number

I remain dubious about the defining a parameter for the Reason header field that is not intended to ever appear in a Reason header field of any sip request - instead only to appear embedded in a URI when that URI is placed in a H-I header. This is a hack.

	Thanks,
	Paul

_________________________________________________________________________________________________________________________

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: Mary Barnes <[email-masked]>
Date: Wed, 20 May 2015 16:36:41 -0500

I'm reviewing this document in anticipation of doing the shepherd write-up
and I have a few comments about this particular thread of discussion below
[MB].

Mary.

On Mon, May 4, 2015 at 4:26 AM, <[email-masked]> wrote:

> field that is not intended to ever appear in a Reason header field of any
> sip request - instead only to appear embedded in a URI when that URI is
> placed in a H-I header. This is a hack.
>
> But
> -1st, this draft it is not at all about a parameter for the Reason header
> field. It is a new value for the "cause" parameter which is a SIP/SIPS URI
> parameter.
> -2nd, it is not required to be embedded in a URI only when that URI is
> placed in a H-I header (see following extract):

[MB] Really, you're actually just defining a new  "cause" URI parameter
value which can be added to the  Request-URI.  Note, this "cause" URI
parameter is NOT the same as the "cause" header field parameter in the
Reason header field.  It was perhaps quite unfortunate that RFC 4458 and
RFC 3326 used the same name for two slightly different things.   And, if
there is a hack, that hack was added when the "cause" URI parameter was
defined in RFC 4458 to handle voicemail (which is yet another service in a
similar vein as the service this document is trying to accommodate).  It
just so happens that this will work for this Service Number translation
because History-Info will capture that information when it captures the
Request-URI, but this "cause" is NOT the same "cause" as that captured in
the Reason header field (there are 2 different IANA registries), as
evidenced in the example that Marianne included in the -02.   The fact that
the "cause" is part of the Request-URI should be transparent to
History-Info.    So, I think that some edits are needed in this document to
make that clear.  I will suggest those in a separate email. [/MB]

>
> However, to make it more explicit I'm going to update the draft to add
> this cause in the R-URI of the example in section 4 and improve the
> sentence above-mentioned.
>
> Best regards,
> Marianne
>
> Objet : Re: [dispatch] WG review of
> draft-mohali-dispatch-cause-for-service-number
>
> <http://mailarchive.ietf.org/arch/msg/dispatch/DODROdsfVcGNgY04itQn7CFzt0c
> >
>
> field that is not intended to ever appear in a Reason header field of any
> sip request - instead only to appear embedded in a URI when that URI is
> placed in a H-I header. This is a hack.
>
>         Thanks,
>         Paul
>
> > Regards,
> > Mary Barnes
> > DISPATCH WG co-chair
> >
> >
> 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: Thu, 21 May 2015 11:05:03 -0400

On 5/20/15 5:36 PM, Mary Barnes wrote:
> I'm reviewing this document in anticipation of doing the shepherd
> write-up and I have a few comments about this particular thread of
> discussion below [MB].
>
> Mary.
>
> On Mon, May 4, 2015 at 4:26 AM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Dear Paul,
>
>     You say:
>     -1st, this draft it is not at all about a parameter for the Reason
>     header field. It is a new value for the "cause" parameter which is a
>     SIP/SIPS URI parameter.
>     -2nd, it is not required to be embedded in a URI only when that URI
>     is placed in a H-I header (see following extract):
> Reason header field.

Ah! That hadn't dawned on me. Sorry about that. :-(

> It was perhaps quite unfortunate that RFC 4458 and
> RFC 3326 used the same name for two slightly different things.

Yeah.

>  And, if
> defined in RFC 4458 to handle voicemail (which is yet another service in
> a similar vein as the service this document is trying to accommodate).
> It just so happens that this will work for this Service Number
> translation because History-Info will capture that information when it
> captures the Request-URI, but this "cause" is NOT the same "cause" as
> that captured in the Reason header field (there are 2 different IANA
> registries), as evidenced in the example that Marianne included in the
> -02.   The fact that the "cause" is part of the Request-URI should be
> transparent to History-Info.    So, I think that some edits are needed
> in this document to make that clear.  I will suggest those in a separate
> email. [/MB]

Sounds good.

	Thanks,
	Paul

>     However, to make it more explicit I'm going to update the draft to
>     add this cause in the R-URI of the example in section 4 and improve
>     the sentence above-mentioned.
>
>     Best regards,
>     Marianne
>
>     De : dispatch [mailto:[email-masked]
>     <mailto:[email-masked]>] De la part de Paul Kyzivat
>     À : [email-masked] <mailto:[email-masked]>
>     I remain dubious about the defining a parameter for the Reason
>     header field that is not intended to ever appear in a Reason header
>     field of any sip request - instead only to appear embedded in a URI
>     when that URI is placed in a H-I header. This is a hack.
>
>              Thanks,
>              Paul
>
>      > Regards,
>      > Mary Barnes
>      > DISPATCH WG co-chair
>      >
>      >
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     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;
>     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.
>
>     [email-masked] <mailto:[email-masked]>