Subject: [sipping] media-policy, data sets and IANA xml registry

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 7 Nov 2005 21:20:06 -0700

A number of Internet-Drafts are defining new XML elements whose values or attribute values are registered with IANA.

The codecs element in the media policy framework is a good example:
  |      <codecs excluded-policy="allow">
  |      <codec policy="disallow">
  |        <mime-type>audio/G729</mime-type>
                      ^^^^^^^^^^
  |      </codec>

Have there been any thoughts given to XMLizing the IANA registries so that a schema definition could provide stronger typing?
  |        <xs:element name="mime-parameter" type="xs:string"

Being able to fetch or import the MIME media type and sub-type table from the IANA RTP parameters registry (http://www.iana.org/assignments/rtp-parameters) directly in XML would provide some advantages. It is sometimes easy for implementers to mix up the codec name and its actual mime type (G.711 instead of PCMA/PCMU) or insert a dot in the encoding name (G.729 instead of G729). 

Any thoughts on this?

Jean-François
PS: a side comment on http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-policy-dataset-00.txt, is there any reason why you have no separated the mime-type element into 2 distinct ones, mime-type and mime-subtype elements? This would allow media policies to be based on mime-types only (Cullen's "disallow video" example at the mike today).

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Volker Hilt <[email-masked]>
Date: Mon, 07 Nov 2005 23:39:52 -0800

Jean-Francois Mule wrote:
  > Jean-François PS: a side comment on
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-policy-dataset-00.txt,
> is there any reason why you have no separated the mime-type element
> into 2 distinct ones, mime-type and mime-subtype elements? This would
> allow media policies to be based on mime-types only (Cullen's
> "disallow video" example at the mike today).
> 
There is the <media-types> element, which allows the definition of media 
type policies (such as the "disallow video" policy).

The element you've mentioned defines codec policies. If the mime-type 
and mime-subtype are separated, both would need to be present to define 
a codec. For this reason, it seems simpler to have just one element that 
covers both. The only reason I can think of for having two separate 
elements is that it might be easier to parse. Is this an issue?

Thanks,

Volker

-- 
Volker Hilt                      Bell Labs / Lucent Technologies
phone: +1 732 332 6432           101 Crawfords Corner Rd
email: [email-masked]     Holmdel, NJ 07733