Subject: PINT format specific attribute ABNF

From: [email-masked] (Lawrence Conroy)
Date: Sun, 3 Jan 1999 17:22:40 +0000

Whilst grinding through the ABNF for PINT, and checking this against a
parser, I came to the conclusion that a small change to the ABNF covering
the format specific parameter attribute line may be useful.

---------------------------------------------------------------------------

(Herewith the (pretty) basic definition of format specific attributes from
RFC2327:

   a=fmtp:<format> <format specific parameters>
       This attribute allows parameters that are specific to a
       particular format to be conveyed in a way that SDP doesn't have
       to understand them.  The format must be one of the formats
       specified for the media.  Format-specific parameters may be any
       set of parameters required to be conveyed by SDP and given
       unchanged to the media tool that will use this format.

       It is a media attribute, and is not dependent on charset.
)

At present, the ABNF for PINT format-specific parameter attribute lines is:
    "a=fmtp:" <media subtype> 1*<resolution>
where:
    <resolution> = (<uri-ref> | <sub-part-ref> | <opaque-ref>)
and:
    <uri-ref> = URI-reference ; (as defined in rfc2395, appx. A)
    <sub-part-ref> = Content-ID ; (def. in RFC2045, appendix A & RFC822)

The current draft suggests that a <resolution> is of the <sub-part-ref>
form IF it contains an "@", AND that character occurs before any included
":" character, whilst it is of the <uri-ref> form IF it contains a ":"
character, and that character occurs before any contained "@" character.

The current draft suggests that the <opaque-ref> form should be assumed IF
the associated media line has a <media format> that starts with an X-token.

An alternative approach seems to be that, if a <resolution> is in neither
of the other forms, then it must be of the <opaque-ref> form.

The problem::
To say the least, this latter approach makes an ABNF definition of
<opaque-ref> challenging, whilst the former alternative precludes any other
<media format> that starts with an X-token and is resolved using the
<uri-ref> or <sub-part-ref> forms.

Whilst these sub-type definitions are discouraged (see RFC2048, section
2.1.4), they ARE still used, and it is unfortunate overly to restrict them.
For example, I still get items with a MIME content type
"application/x-mswd" (even though there has been an IANA registration for
"application/msword" since 1994 :). In addition, the current draft does
overlay another meaning on the "X-token" message formats when used within
PINT service descriptions that may be undesirable.

The solution::
I propose that explicit tags should be used at the start of each <resolution>.

This should remove restrictions on the character set and patterns that are
available for the <opaque-ref> form, whilst also removing the special
meaning from preceding <media format> tokens.

I suggest the following ABNF.

    "a=fmtp:" <media subtype> 1*<resolution>
where:
    <resolution> := (<urref> | <sub-part-ref> | <opaque-ref>)
and:
    <uri-ref> is ("uri:" URI-reference) ; (def. in rfc2395, appx.A)
    <sub-part-ref> := ("spr:" Content-ID) ; (def. in RFC2045, appx.A & RFC822)
    <opaque-ref> := ("opr:" 1*URIC) ; (def. in RFC2396, appx.A)

Apart from simplifying the ABNF, this has a couple of other benefits.

(i)   it should simplify the parser.
(ii)  it means that the "PINT-specific" ABNF is reduced - there are just
      references to other documents.
(iii) it clarifies (and simplifies) the ABNF for the media line; there is not
      special meaning for a <message format> that starts with an X-token.
      One could still use a message format like "X-ivr.com" as in the example
      in section 4.8 of the curent draft, but one doesn't NEED it.
(iv)  it allows the receiving gateway's support for the "in-line" and "opaque
      reference" to be confirmed. Thus, it allows:
      "strict:org.ietf.pint.spr", or "strict:org.ietf.pint.opr" (or even
      "strict:org.ietf.pint.uri").
(v)   it allows a mixture of opaque reference resolutions to be combined with
      uri references or subpart references when the service definition calls
      for a sequence of objects to be processed.

----------------------

The ABNF for the media line is then ->VERY<- similar to that within RFC2327:

(The original SDP definitions are:
   media-field =         "m=" media space port ["/" integer]
                         space proto 1*(space fmt) CRLF

   media =               1*(alpha-numeric)
                         ;typically "audio", "video", "application"
                         ;or "data"

   alpha-numeric =       ALPHA | DIGIT

   DIGIT =               "0" | POS-DIGIT

   POS-DIGIT =           "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"

   ALPHA =               "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|
                         "l"|"m"|"n"|"o "|"p"|"q"|"r"|"s"|"t"|"u"|"v"|
                         "w"|"x"|"y"|"z"|"A"|"B"|"C "|"D"|"E"|"F"|"G"|
                         "H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|" Q"|"R"|
                         "S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"

   space =               %d32

   port =                1*(DIGIT)
                         ;should in the range "1024" to "65535" inclusive
                         ;for UDP based media

   proto =               1*(alpha-numeric)
                         ;typically "RTP/AVP" or "udp" for IP4

   fmt =                 1*(alpha-numeric)
                         ;typically an RTP payload type for audio
                         ;and video media
)

For the PINT profile, this changes (slightly) to:
    media-field =       "m=" media space port space proto 0*(space fmt) CRLF

Within the PINT profile, the notes for the ABNF items differ, the optional
["/" integer] sub-field has been removed, and the fmt field has been
changed so that it can be empty (under some circumstances).

The related PINT notes for each of the fields are:

*    The media field value is one of the top-level MIME types, as defined in
     RFC2045.
     (see also <ftp://ftp.isi.edu/in-notes/iana/assignments/media-types>)

*    The port MUST be "0"

*    The proto field is restricted to ("phone"|"fax"|"pager").
     This indicates the form of the eventual multimedia session intended to
     result from this service request. Thus, "phone" indicates that the
     resulting call will involve telephones, "fax" indicates that it should
     result in a fax transmission, whilst "pager" is included where the result
     will be a message sent to a pager device.

*    The fmt field may contain a list of items, each of which is a MIME
     sub-type associated with the "top level" type held in the media field, as
     defined in RFC2045.
     (see also <ftp://ftp.isi.edu/in-notes/iana/assignments/media-types>)

     Each individual fmt item will have an associated format-specific
     attribute line resolving the source (or sources) of the data object(s)
     the type of which is defined by the combination of the media field and
     the fmt item.

     If the fmt field is empty, it implies both that the information to be
     exchanged as part of any telephone network call resulting from this
     service request has an implicit source within the GSTN, and also that the
     sub-type is also implicit. Of the PINT "reference" services, this occurs
     with a "Request To Call" service, in which case the media line will be of
     the form:
     m=audio 0 phone

---------------------------------------------------------------------------

Does anyone have any objection to prepending explicit tags to the format
specific parameters? If so, please speak up, or this change will find its
way into future drafts (both as an ABNF section and as part of the promised
rewrite of 3.4.2).

All the best, Lawrence
-----------------------------------------------------------------------
| Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
| Roke Manor Research |  were my Company's they'd charge you for them"|
|- [email-masked]  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|

---------
This message came from the IETF PINT Working Group Mailing List.