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

[Mary Barnes <[e-mail]>]

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, <[e-mail]> wrote:

> 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.
>

[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
>
> -----Message d'origine-----
> De : dispatch [mailto:[e-mail]] De la part de Paul
> Kyzivat
> Envoyé : vendredi 1 mai 2015 16:26
> À : [e-mail]
> Objet : Re: [dispatch] WG review of
> draft-mohali-dispatch-cause-for-service-number
>
> 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-servic
> > e-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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> 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.
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>