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

["A. Jean Mahoney" <[e-mail]>]

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.

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.


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.


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?

    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:

    [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:

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

    [M4A]      Apple, "Apple Lossless Audio Codec",
               <https://macosforge.github.io/alac/>

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


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/>>
>>> www.sipforum.org <http://www.sipforum.org/>
>>>
>>> richard<at>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]>> on behalf 
>>> [e-mail] 
>>> <mailto:[e-mail]><mailto:[e-mail] 
>>> <mailto:[e-mail]>>" <[e-mail] 
>>> <mailto:[e-mail]><mailto:[e-mail] 
>>> <mailto:[e-mail]>> on behalf 
>>> [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/>::internet-drafts
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> [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]>
>>> https://www.ietf.org/mailman/listinfo/sipcore 
>>> <https://www.ietf.org/mailman/listinfo/sipcore>
>>
>