Re: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-rcd-09.txt

[Chris Wendt <[e-mail]>]

Hi Jean,

Thanks again for the additional feedback, i have incorporated your feedback with a few tweaks, details inline below.
Will submit a -10 for review.

-Chris

> On Mar 22, 2024, at 3:15 PM, A. Jean Mahoney <[e-mail]> wrote:
> 
> Chris,
> 
> On 3/21/24 10:55 PM, Chris Wendt wrote:
>> Hi Sipcore, Jean,
>> After a few offline and in person conversations at IETF this week, i’ve decided not to do any more updates to this draft.  
> 
> [JM] Thank you for update.
> 
> 
> So, i think it’s
>> ready to proceed, given there are no last minute comments from the working group.
> 
> [JM] I do have some feedback regarding references and a few normative statements:
> 
> Normative vs Informative References:
> 
> There are only normative references listed in this document. Please consider whether some could be listed as informative. For example, the following downrefs to RFCs 7340 and 3325 have been found by idnits in Sections 1 and 4 (please see RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs).
> 
> RFC 7340 "Secure Telephone Identity Problem Statement and Requirements":
> 
> Section 1:
> 
>   Therefore, the
>   recommended approach is that the entity inserting the Call-Info
>   header field should also sign the caller information via STIR-defined
>   protocol tools [RFC7340] for SIP [RFC8224] and specifically through
>   the use of RCD or the "rcd" PASSporT defined in
>   [I-D.ietf-stir-passport-rcd].
> 
> Section 4:
> 
>   The
>   STIR framework [RFC7340] addresses the protection of the carriage of
>   call information and identities over untrusted networks, which wasn't
>   addressed in the core SIP specifications.
> 
> draft-ietf-stir-passport-rcd lists [RFC7340] as an informative reference.  Recommend moving the reference to the Informative References section.

made this informative

> 
> RFC 3325 "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks":
> 
> Section 4:
> 
>   Alternatively, for some calls, the calling name may come
>   from the P-Asserted-ID header field [RFC3325].
> 
> draft-ietf-stir-passport-rcd lists [RFC3325] as an informative reference.  Recommend moving the reference to the Informative References section.
> 

made this informative

> 
> Obsolete Reference:
> 
> Section 5:  The following normative text references an obsolete RFC:
> 
>   The media type for
>   the JSON text MUST be set as application/json with a default encoding
>   of UTF-8 [RFC4627].
> 
> The current RFC is RFC 8259 "The JavaScript Object Notation (JSON) Data Interchange Format". Recommend updating.

updated

> 
> 
> Missing References:
> 
> Section 8.2:  Perhaps references should be provided for PNG, JPEG, BMP, MP3, ALAC (M4A), and WAV. As for WAV, though, it appears that Microsoft has deprecated it: <https://learn.microsoft.com/en-us/windows/win32/multimedia/waveform-audio>. Do we want to specify something else?

WAV is still a widely supported format for storing uncompressed PCM audio, so i think it should stay, it is a form of the RIFF file format, but unfortunately there is no official specification that is maintained.

I will reference rfc2361 which is not a format spec but contains a registry of microsoft wav and avi formats.

> 
>   For images, such as for the "photo" and "logo" properties, the
>   default image formats SHOULD be PNG or JPEG, as these files are
>   commonly used to support 24-bit RGB images.
> 
>   Supporting older
>   telephone devices that only support bitmap (BMP) images ...
> 
>   For audio files, the recommendation is to provide mp3, m4a, or wav
>   files,
> 
> Suggested Normative References:

>   [BMP]      Microsoft, "Bitmaps (Windows GDI)", January 2021,
>              <https://learn.microsoft.com/en-us/windows/win32/
>              gdi/bitmaps>

RFC7903 is better reference

> 
>   [JPEG]     ITU-T, "Information technology -- Digital compression and
>              coding of continuous-tone still images: JPEG File
>              Interchange Format (JFIF)", ITU-T Recommendation T.871,
>              ISO/IEC 10918-5:2013, May 2013.
> 
>   [PNG]      ISO/IEC, "Information technology -- Computer graphics and
>              image processing -- Portable Network Graphics (PNG):
>              Functional specification", ISO/IEC 15948:2004, March 2004.
> 
> Suggested Informative References:
> 
> # Moved BMP to Normative
> 
> #  [M4A]      Apple, "Apple Lossless Audio Codec”,
> #            <https://macosforge.github.io/alac/>
> #

[M4A] "ISO/IEC 14496-3:2009 - Information technology -- Coding of audio-visual objects -- Part 3: Audio" <http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=53943>. ISO <https://en.wikipedia.org/wiki/International_Organization_for_Standardization>. 2009.

>   [MP3]      ISO/IEC, "Information technology -- Generic coding of
>              moving pictures and associated audio information -- Part
>              3: Audio", ISO/IEC 13818-3:1998, April 1998.
> 
> 
> Clarifying Normative Statements:
> 
> Should SVG be added to the following statement?
> 
>   For images, such as for the "photo" and "logo" properties, the
>   default image formats SHOULD be PNG or JPEG, as these files are
>   commonly used to support 24-bit RGB images.
> 
> Or should the "should" here be normative?
> 
>   At a minimum, the SVG
>   Tiny 1.2 specification [W3C-SVGTiny1.2] should be supported as an
>   additional default format for devices.

I did make it normative

> 
> 
> Best regards,
> Jean
> 
> 
>> Thanks!
>> -Chris
>>> On Mar 10, 2024, at 1:03 AM, Chris Wendt <[e-mail]> wrote:
>>> 
>>> Hi Richard,
>>> 
>>> Thanks for asking :)
>>> 
>>> Sipcore WG,
>>> 
>>> I’ve updated the draft to incorporate all of the excellent comments and suggestions and fixes made by Jean in her review (Thanks Jean for your comprehensive review!!!)
>>> 
>>> There is one more additional thing i plan to submit next week that came up in some industry RCD discussions recently once the draft submission tool opens back up into the Brisbane meeting, but hopefully the document should be pretty close to ready to progress barring any other major comments.
>>> 
>>> Thanks for everyone's patience, but it does seem this document will be getting some industry adoption and there seems to be a lot of eyes on it and implementation happening and good feedback has been received.  So, that is all good as we are wrapping it up.
>>> 
>>> Thanks!!
>>> 
>>> -Chris
>>> 
>>>> On Mar 6, 2024, at 11:45 AM, Richard Shockey <[e-mail]> wrote:
>>>> 
>>>> 
>>>> Are we done yet?
>>>> 
>>>> Richard Shockey
>>>> Shockey Consulting LLC
>>>> Chairman of the Board SIP Forum
>>>> www.shockey.us <http://www.shockey.us/> <http://www.shockey.us/><http://www.shockey.us <http://www.shockey.us/> <http://www.shockey.us/>>
>>>> www.sipforum.org <http://www.sipforum.org/> <http://www.sipforum.org/>
>>>> 
>>>> richard<at>shockey.us <http://shockey.us/> <http://shockey.us/>
>>>> Skype-Linkedin-Facebook –Twitter rshockey101
>>>> PSTN [phone]
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 3/2/24, 11:26 AM, "[e-mail] <mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>> on behalf [e-mail] <mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>> on behalf [e-mail] <mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>>> 
>>>> 
>>>> Internet-Draft draft-ietf-sipcore-callinfo-rcd-09.txt is now available. It is
>>>> a work item of the Session Initiation Protocol Core (SIPCORE) WG of the IETF.
>>>> 
>>>> 
>>>> Title: SIP Call-Info Parameters for Rich Call Data
>>>> Authors: Chris Wendt
>>>> Jon Peterson
>>>> Name: draft-ietf-sipcore-callinfo-rcd-09.txt
>>>> Pages: 24
>>>> Dates: 2024-03-02
>>>> 
>>>> 
>>>> Abstract:
>>>> 
>>>> 
>>>> This document describes a usage of the SIP Call-Info header field
>>>> that incorporates Rich Call Data (RCD) associated with the identity
>>>> of the calling party in order to provide to the called party a
>>>> description of the caller or details about the reason for the call.
>>>> RCD includes information about the caller beyond the telephone number
>>>> such as a calling name, or a logo, photo, or jCard object
>>>> representing the caller, which can help the called party decide
>>>> whether to answer the phone. The elements defined for this purpose
>>>> are intended to be extensible in order to accommodate related
>>>> information about calls and to be compatible and complimentary with
>>>> the STIR/PASSporT RCD framework.
>>>> 
>>>> 
>>>> This document defines a new parameter ('call-reason') for the SIP
>>>> Call-Info header field and also a new token ("rcd-jcard") for the
>>>> 'purpose' parameter of the Call-Info header field. It also provides
>>>> guidance on the use of the Call-Info 'purpose' parameter token,
>>>> "icon".
>>>> 
>>>> 
>>>> The IETF datatracker status page for this Internet-Draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-rcd/ <https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-rcd/><https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-rcd/ <https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-rcd/>>
>>>> 
>>>> 
>>>> There is also an HTMLized version available at:
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-callinfo-rcd-09 <https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-callinfo-rcd-09><https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-callinfo-rcd-09 <https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-callinfo-rcd-09>>
>>>> 
>>>> 
>>>> A diff from the previous version is available at:
>>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-sipcore-callinfo-rcd-09 <https://author-tools.ietf.org/iddiff?url2=draft-ietf-sipcore-callinfo-rcd-09><https://author-tools.ietf.org/iddiff?url2=draft-ietf-sipcore-callinfo-rcd-09 <https://author-tools.ietf.org/iddiff?url2=draft-ietf-sipcore-callinfo-rcd-09>>
>>>> 
>>>> 
>>>> Internet-Drafts are also available by rsync at:
>>>> rsync.ietf.org <http://rsync.ietf.org/> <http://rsync.ietf.org/>::internet-drafts
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>
>>>> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore><https://www.ietf.org/mailman/listinfo/sipcore<https://www.ietf.org/mailman/listinfo/sipcore>>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>
>>> 
> 
> _______________________________________________
> sipcore mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/sipcore