Re: [sipcore] TR: New Version Notification for draft-mohali-rfc6044bis-00.txt

[<[e-mail]>]

Hello Paul and Mary,

It is clear for me that this draft will follow the same route than RFC6044 as an independent submission and not a WG document.
Because this draft is related to RFC7044 (a sipcore document), my intention was just to inform people working on that topic about the new draft. That's why my email was "for your information".

Thank you

Best Regards,
Marianne

De : sipcore [mailto:[e-mail]] De la part de Mary Barnes
Envoyé : vendredi 14 février 2014 23:21
À : Paul Kyzivat
Cc : SIPCORE
Objet : Re: [sipcore] TR: New Version Notification for draft-mohali-rfc6044bis-00.txt

Paul,

RFC 6044 was not a product of any IETF WG.  Robert, was the shepherd and the IESG reviewed but the criteria are different in the case that the document is being considered for the independent stream:



  "This is a contribution to the RFC Series, independently of

   any other RFC stream.  The RFC Editor has chosen to publish

   this document at its discretion and makes no statement



   about its value for implementation or deployment.  Documents

   approved for publication by the RFC Editor are not a

   candidate for any level of Internet Standard;



   see Section 2 of RFC 5741.

My recommendation is then that the same route is the only reasonable one for any updates to RFC 6044.  Note, that this RFC has a normative dependency on the Diversion-header (RFC 5806) that was also published in the independent stream.

It should not go to DISPATCH unless we want to waste our time rehashing the debate we had many times and we ultimately decided not to accept this as a work item in any of the WGs.  Some of the earlier discussion was in the SIPPING WG prior to the chartering of DISPATCH.

Mary.

On Fri, Feb 14, 2014 at 1:22 PM, Paul Kyzivat <[e-mail]<mailto:[e-mail]>> wrote:
Marianne,

I see you have sent this mail to sipcore, but the individual draft itself doesn't indicate a wg. Looking back at how 6044 was handled, all the discussion I can find was on the bliss wg mailing list. But it never became a wg document there or sipcore. I gather it was progressed as AD sponsored?

IMO sipcore isn't the proper place to discuss this. Maybe dispatch.

        Thanks,
        Paul (as sipcore co-chair)


On 2/14/14 1:58 PM, [e-mail]<mailto:[e-mail]> wrote:
Hi folks,

FYI
Following RFC7044 publication (History-Info bis), here is a first version of the RFC6044bis (draft-mohali-rfc6044bis-00) proposing a mapping between History-Info header field and Diversion header field (RFC5806).

Best Regards,
Marianne

-----Message d'origine-----
De : [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>]
Envoyé : vendredi 14 février 2014 18:50
À : MOHALI Marianne IMT/OLN; MOHALI Marianne IMT/OLN
Objet : New Version Notification for draft-mohali-rfc6044bis-00.txt


A new version of I-D, draft-mohali-rfc6044bis-00.txt has been successfully submitted by Marianne Mohali and posted to the IETF repository.

Name:           draft-mohali-rfc6044bis
Revision:       00
Title:          Mapping and interworking of Diversion information Between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)
Document date:  2014-02-14
Group:          Individual Submission
Pages:          25
URL:            http://www.ietf.org/internet-drafts/draft-mohali-rfc6044bis-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mohali-rfc6044bis/
Htmlized:       http://tools.ietf.org/html/draft-mohali-rfc6044bis-00


Abstract:
    [This version of the document is a draft version for an RFC6044bis
    that will describe the mapping between the Diversion header defined
    in RFC5806 and the new History-Info header defined in RFC7044.]
    Although the SIP History-Info header is the solution adopted in IETF,
    the non-standard Diversion header is nevertheless already implemented
    and used for conveying call diversion related information in the
    Session Initiation Protocol (SIP) signaling.
    This document describes a recommended interworking guideline between
    the Diversion header and the History-Info header to handle call
    diversion information.  In addition, an interworking policy is
    proposed to manage the headers' coexistence.  The non-standard
    Diversion header is described, as Historic, in [RFC5806].  The
    History-Info header is described in [RFC7044] that obsoletes
    [RFC4244] initially describing the History-Info header.  [RFC7044]
    defines an optional SIP header field, History-Info, for capturing the
    history information in requests and SIP header field parameters for
    the History-Info and Contact header fields to tag the method by which
    the target of a request is determined.  RFC7044 also defines a value
    for the Privacy header field that directs the anonymization of values
    in the History-Info header field.

    Since the Diversion header is used in existing network
    implementations for the transport of call diversion information, its
    interworking with the SIP History-Info standardized solution is
    needed.  This work is intended to enable the migration from non-
    standard implementations and deployment toward IETF specification-
    based implementations and deployment.
    This document obsoletes [RFC6044].




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<http://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.

_______________________________________________
sipcore mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sipcore


_________________________________________________________________________________________________________________________

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.