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

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 8 Nov 2005 12:23:21 -0700

Volker wrote:
> 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?

What originally prompted my comments is the fact that in draft-petrie-sipping-profile-datasets-03.txt, we have:
   <codecs excluded_policy='disallow'>
     <codec policy='allow'>PCMA</codec>
     <codec policy='allow'>G729</codec>
   </codecs>
I understand this may just be an I-D sync issue but I thought it was more readable (not necessarily a good argument for requesting a change).

Back to your question, I'm not an xml expert but given the markup capabilities, I would think it is a plus to split the elements rather than having a complex element that you need to xml parse then further parse the value of, in order to potentially get the atomic values...

Now the point may be moot if the use of the value is only going to be in the form of mime-type/mime-subtype (but I doubt it).

Jean-François

_______________________________________________
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: Tue, 08 Nov 2005 18:37:11 -0800

Jean-Francois Mule wrote:
> What originally prompted my comments is the fact that in
> draft-petrie-sipping-profile-datasets-03.txt, we have:
> I understand this may just be an I-D sync issue but I thought it was
> more readable (not necessarily a good argument for requesting a change).
> 
Yup, this is an I-D sync artifact (and human XML readability wasn't the 
driver behind the change :) ). The new structure is more precise since 
it exactly mirrors the MIME type definition. In addition, it also 
supports parameters.

> Back to your question, I'm not an xml expert but given the markup
> capabilities, I would think it is a plus to split the elements rather
> than having a complex element that you need to xml parse then further
> parse the value of, in order to potentially get the atomic values...
> 
> Now the point may be moot if the use of the value is only going to be
> in the form of mime-type/mime-subtype (but I doubt it).
> 
Thats exactly the definition of this element.

But I agree that it is maybe a cleaner solution to use two separate 
elements instead.

Volker