Subject: [RAI] RFC errata report on erra 1999, 1997, and 1998 to RFC 5688 (A SIP Media Feature Tag for MIME Application Subtypes) and erratum 2091 to RFC 5727 (Change Process for SIP and the RAI Area)

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 7 Jan 2011 10:52:20 -0500

======================================================================
RFC5688, "A Session Initiation Protocol (SIP) Media Feature Tag for
MIME Application Subtypes"
Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 1999

Status: Reported
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2010-01-10

Section 3, 1st para says:

   The 'sip.app-subtype' media feature tag is of type token with a case-
   insensitive equality relationship.  Its value can be any registered
|  or private MIME application subtype compliant to the subtype-name
   grammar defined in [RFC4288].  When included in the Contact header
   field of a REGISTER request, an agent SHOULD include all application
   subtypes that it can support as streaming formats.  An application
|  subtype is supported if the user agent would be capable of processing
   a Session Description Protocol (SDP) [RFC4566] offer [RFC3264] that
   contained that subtype as a format in the m-line of the SDP.

It should say:

   The 'sip.app-subtype' media feature tag is of type token with a case-
   insensitive equality relationship.  Its value can be any registered
|  or private 'application' media subtype compliant to the subtype-name
   grammar defined in [RFC4288].  When included in the Contact header
   field of a REGISTER request, an agent SHOULD include all application
   subtypes that it can support as streaming formats.  An application
|  subtype is supported if the user agent would be capable of accepting
   a Session Description Protocol (SDP) [RFC4566] offer [RFC3264] that
   contained that subtype as a format in the m-line of the SDP.

Notes:

Rationale:

For clarity, the whole paragraph is shown here, including both changes.

a) editorial; see GLOBAL Errata note, EID=1997.

b) technical: the ability of "processing" an SDP offer does not
mean the ability to _accept_ it. The latter reasonably seems
to be synonymous to "supporting" the feature contained therein,
but the former isn't. Therefore, s/processing/accepting/ .
----------------------------------------------------------------------
Recommended status:  (correct) Hold for document update
Type: Editorial

I recommend removing the subjunctive from the final sentence of the
paragraph, along with some other changes:

   An application
   subtype is "supported" if the user agent can usefully accept
   a Session Description Protocol (SDP) [RFC4566] offer [RFC3264] that
   contains that subtype as the sole format in the sole m-line of the SDP.
======================================================================
RFC5688, "A Session Initiation Protocol (SIP) Media Feature Tag for
MIME Application Subtypes"
Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 1997

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-01-10

Throughout the document, when it says:

a)   document title:

     A Session Initiation Protocol (SIP) Media Feature Tag for MIME
                          Application Subtypes

b)   Abstract

   The caller preferences specification for the Session Initiation
   Protocol (SIP) allows a caller to express preferences that the call
   be routed to a User Agent (UA) with particular capabilities.
   Similarly, a specification exists to allow a UA to indicate its
   capabilities in a registration.  Amongst those capabilities are the
|  type of media streams the agent supports, described as top-level MIME
|  types.  The 'application' MIME type is used to describe a broad range
   of stream types, and it provides insufficient granularity as a
   capability.  This specification allows a UA to indicate which
   application subtypes the agent supports.

c)  Section 3, 1st para

   The 'sip.app-subtype' media feature tag is of type token with a case-
   insensitive equality relationship.  Its value can be any registered
|  or private MIME application subtype compliant to the subtype-name
   grammar defined in [RFC4288].  [...]

[[ see also subsequent errata note covering another issue as well ! ]]

d)  Section 3, 3rd para

   It is important to note that this media feature tag is only
   indicating the streaming media types that a user agent is capable of
   supporting.  It says nothing about the functionality provided by the
|  user agent itself or the MIME types that the agent can send or
   receive in SIP messages or emails.  For example, let us assume that a
   SIP user agent is capable of supporting a chess game.  The game is
   played by each user sending chess moves as binary objects over UDP
|  between a pair of user agents.  Those objects have a MIME type of
   "application/example".  [...]

e)  Section 3, 4th para

   A consequence of this is that, as new streaming media type formats
   are defined (such as game stream formats, whiteboard session formats,
   and so on), they SHOULD be defined using the SDP application stream
|  and utilize a MIME application subtype.

f)  Section 6, 4th para

   Summary of the media feature indicated by this tag:  This feature tag
|     indicates the MIME application subtypes supported by the agent for
      purposes of streaming media.

It should say:

a)
        A Session Initiation Protocol (SIP) Media Feature Tag for
                      'Application' Media Subtypes

b)

   The caller preferences specification for the Session Initiation
   Protocol (SIP) allows a caller to express preferences that the call
   be routed to a User Agent (UA) with particular capabilities.
   Similarly, a specification exists to allow a UA to indicate its
   capabilities in a registration.  Amongst those capabilities are the
|  type of media streams the agent supports, described as top-level media
|  types.  The 'application' media type is used to describe a broad range
   of stream types, and it provides insufficient granularity as a
   capability.  This specification allows a UA to indicate which
   application subtypes the agent supports.

c)

   The 'sip.app-subtype' media feature tag is of type token with a case-
   insensitive equality relationship.  Its value can be any registered
|  or private 'application' media subtype compliant to the subtype-name
   grammar defined in [RFC4288].  [...]

d)
   It is important to note that this media feature tag is only
   indicating the streaming media types that a user agent is capable of
   supporting.  It says nothing about the functionality provided by the
|  user agent itself or the media types that the agent can send or
   receive in SIP messages or emails.  For example, let us assume that a
   SIP user agent is capable of supporting a chess game.  The game is
   played by each user sending chess moves as binary objects over UDP
|  between a pair of user agents.  Those objects have a media type of
   "application/example".  [...]

e)

   A consequence of this is that, as new streaming media type formats
   are defined (such as game stream formats, whiteboard session formats,
   and so on), they SHOULD be defined using the SDP application stream
|  and utilize an 'application' media subtype.

f)

   Summary of the media feature indicated by this tag:  This feature tag
|     indicates the 'application' media subtypes supported by the agent
      for purposes of streaming media.

Notes:

Rationale:
The subject of the RFC is SIP, not e-Mail, the 3rd letter in "MIME".
Therefore, the RFC should better follow the explanations given in
RFC 4288, which places the original concepts from MIME that have
proven generally useful into a more general context and strongly
recommends talking about "media types" and "media subtypes".
That reasoning similarly holds for Media Features, which for
obvious reasons not have been denoted "MIME Features".
----------------------------------------------------------------------
Recommended status:  (correct) Hold for document update
Type: Editorial
======================================================================
RFC5688, "A Session Initiation Protocol (SIP) Media Feature Tag for
MIME Application Subtypes"
Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 1998

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-01-10

Section 1, 4th para says:

   RFC 3840 defines media feature tags for each and every top-level
   media type, including 'application'.  This media type covers an
   extremely broad range of subtypes -- multiplayer games of all sorts,
   shared whiteboards and application sharing, and so on.  With audio
|  and video, where there is often a common codec supported by agents
   (i.e., a common subtype).  [...]

It should say:

   RFC 3840 defines media feature tags for each and every top-level
   media type, including 'application'.  This media type covers an
   extremely broad range of subtypes -- multiplayer games of all sorts,
   shared whiteboards and application sharing, and so on.  With audio
|  and video, there is often a common codec supported by agents (i.e.,
   a common subtype).  [...]

Notes:

Rationale: grammar; the original sentence sounds incomplete.
Therefore, strike "where".
----------------------------------------------------------------------
Recommended status:  (correct) Hold for document update
======================================================================
RFC5727, "Change Process for the Session Initiation Protocol (SIP) and
the Real-time Applications and Infrastructure Area"
Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 2091

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-03-21

Section 7. says:

[ 4th para of section, at the bottom of page 11: ]
  
|                                   [...], at the discretion the
   Designated Expert).  Short forms of header fields MUST only be
   assigned to Standards Track header fields.

It should say:

|                                   [...], at the discretion of the
   Designated Expert).  Short forms of header fields MUST only be
   assigned to Standards Track header fields.

Notes:

Rationale: missing word "of".

Remark -- another nit (keep for update):
The trailing period is missing from the first paragraph of Section 1.
----------------------------------------------------------------------
Recommended status:  (correct) Hold for document update
======================================================================

Dale