errata logo graphic

Found 3 records.

Status: Held for Document Update (3)

RFC5688, "A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes", January 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rai

Errata ID: 1999

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2010-01-10
Held for Document Update by: Robert Sparks

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


Errata ID: 1997

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-01-10
Held for Document Update by: Robert Sparks

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


Errata ID: 1998

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-01-10
Held for Document Update by: Robert Sparks

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


Report New Errata