Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16804 for ; Mon, 7 Jul 2003 04:05:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZQzs-0004jQ-5h for avt-archive@odin.ietf.org; Mon, 07 Jul 2003 04:05:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6785GxT018189 for avt-archive@odin.ietf.org; Mon, 7 Jul 2003 04:05:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZQze-0004ik-DA; Mon, 07 Jul 2003 04:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YTjD-0003OQ-Mv for avt@optimus.ietf.org; Fri, 04 Jul 2003 12:48:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01850 for ; Fri, 4 Jul 2003 12:48:04 -0400 (EDT) From: jan.vandermeer@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YTjB-0007nJ-00 for avt@ietf.org; Fri, 04 Jul 2003 12:48:05 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19YTjA-0007nG-00 for avt@ietf.org; Fri, 04 Jul 2003 12:48:04 -0400 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl5.philips.com (Postfix) with ESMTP id CAF3955A01; Fri, 4 Jul 2003 18:48:03 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id SAA29236; Fri, 4 Jul 2003 18:48:03 +0200 (MET DST) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id SAA16414; Fri, 4 Jul 2003 18:48:02 +0200 (MEST) To: mankin@psg.com Cc: avt@ietf.org, casner@acm.org, csp@csperkins.org, dmackie@apple.com, magnus.westerlund@ericsson.com, mankin@psg.com, ned.freed@mrochek.com, philippe.gentric@philips.com, singer@apple.com, smb@research.att.com, viswanathan.swaminathan@sun.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 4 Jul 2003 18:46:34 +0200 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 04/07/2003 18:46:41, Serialize complete at 04/07/2003 18:46:41 Content-Type: multipart/alternative; boundary="=_alternative 005C46FCC1256D59_=" Subject: [AVT] Re: IESG Review of draft-ietf-avt-mpeg4-simple-07.txt - Discuss Comments Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 005C46FCC1256D59_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Allison, all, Thanks for the IESG comments. In response I would like to suggest the=20 following: 1) Comment: It is strange to have more than one section labeled "Introduction." Please pick a new label for section 2.1. My proposal is to label 2.1 as "Signaling by MIME format parameters" 2) Where is the security model defined for ECMAScript in this context?=20 (Problems with the model have been part of the Javascript security=20 problem for Web browsers.) MPEG-4 defines some important constraints on the use of ECMA scripts in=20 MPEG-4. An annex to the MPEG-4 system spec describes the differences=20 between "regular" ECMA scipts and "MPEG-4 scripts". As far as I understand = these constraints do not allow dangerous ECMA script constructs, which=20 means there is no need for an ECMA script security model in this context.=20 Below I attached the MPEG-4 annex that describes the differences.=20 I suggest to resolve this as follows: a) replace in section 5 "security considerations" all current references=20 to ECMAScript by MPEG-4 script, and=20 b) add to the fifth paragraph (starting with "In ISO/IEC 14496-1 a=20 security model is defined for ...") the following trailing sentence "Note: = MPEG-4 scripts are based on ECMA scripts, but there is no need for an ECMA = script security model, as the use of insecure ECMA script constructs is=20 impossible in MPEG-4 scripts." 3) 2.4: Why is this form of application-level fragmentation better than IP fragmentation? This is because of error resilience. If IP fragmentation occurs without=20 application-level fragmentation, then all data of the entire Access Unit=20 gets lost when one such fragmented IP packet is lost. When=20 application-level fragmentation is used, and one RTP packet with an AU=20 fragment gets lost, then the received RTP packet(s) with the other AU=20 fragments can still be decoded. I suggest to remove "so as to avoid IP=20 layer fragmentation" from the first sentence of section 2.4, and to add=20 the following after the first sentence: "Hence when an IP packet is lost=20 after IP-level fragmentation, only an AU fragment may get lost instead of=20 the entire AU". Any comments very welcome. Best regards, Jan van der Meer *******begin of MPEG-4 system annex******* MPEG-4 Scripts Have a Rigid Representation=20 MPEG-4 scripts differ slightly from ECMA scripts. The most important=20 difference is that MPEG-4 scripts are not represented textually, but are=20 transmitted as a parse tree representation. This means that only=20 constructs that can be represented by the MPEG-4 parse grammar can be=20 encoded and transmitted. Not all ECMA script constructs can be represented = in MPEG-4 scripts.=20 The differences between ECMA scripts and scripts that can be represented=20 in MPEG-4 are given below. Keywords MPEG-4 scripts cannot utilize the following keywords: catch delete do final= ly in instanceof throw try typeof void with . This means that do ? while loops and for ? in loops are not possible. Relational operators The relational operators "=3D=3D=3D" and "!=3D=3D" cannot be included in M= PEG-4 Scripts.=20 Labeled statements In MPEG-4 scripts it is impossible to label statements and to break or cont= inue to labeled statements. Switch statement restriction MPEG-4 scripts with switch statements can only take numerical case expressi= ons and always must have at least one case statement. In particular this means that=20 switch { case (x+1): ?. } is not possible, while Switch { case 1: ?. } is okay. Functions, not programs The MPEG-4 event driven script model allows only functions to be called in = response to events.=20 Expressions=20 Statements that include statement blocks, such as for are represented in=20 the parse tree as having an empty statement block, where as in ECMA script = they can omit this block. Functionally, the statements behave identically. = For example, the expression:=20 for ( ; ; )=20 must be represented as for ( ; ; ) {} Array and Object Literals Array and object literals of the form [value1, value2, .., valueN] and {pro= perty1:value1, property2: value2, .. propertyN:valueN} cannot be used in MP= EG-4 scripts.=20 *******end of MPEG-4 system annex******* Allison Mankin 2003-06-27 06:19 AM Please respond to mankin =20 To: Jan vanderMeer/EHV/CE/PHILIPS@EMEA3 dmackie@apple.com viswanathan.swaminathan@sun.com singer@apple.com Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 cc: casner@acm.org magnus.westerlund@ericsson.com csp@csperkins.org smb@research.att.com ned.freed@mrochek.com mankin@psg.com avt@ietf.org Subject: IESG Review of draft-ietf-avt-mpeg4-simple-07.txt -= Discuss Comments Classification:=20 The IESG reviewed draft-ietf-avt-mpeg4-simple-07.txt and had a few=20 concerns that should be addressed before the draft can advance. Editorially: Comment: It is strange to have more than one section labeled "Introduction." Please pick a new label for section 2.1. Steve Bellovin and Ned Freed both request that a reference be given in the Security Considerations for security model for ECMAscript. Here is Steve's Discuss comment: Where is the security model defined for ECMAScript in this context?=20 (Problems with the model have been part of the Javascript security=20 problem for Web browsers.) Steve also asked: 2.4: Why is this form of application-level fragmentation better than IP fragmentation? Please discuss the issues in email and we'll see if the fixes to the draft can be done as notes rather than a revised i-d, to be quicker. Allison --=_alternative 005C46FCC1256D59_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Allison, all,

Thanks for the IESG comments. In res= ponse I would like to suggest the following:

1) Comment:  It is strange to = have more than one section labeled
 "Introduction."  Please pick a new label for section = 2.1.

My proposal is to label 2.1 as "= ;Signaling by MIME format parameters"
2) Where is the security model defi= ned for ECMAScript in this context?  
  (Problems with the model have been part of the Javascript security =
  problem for Web browsers.)
MPEG-4 defines some important constr= aints on the use of ECMA scripts in MPEG-4. An annex to the MPEG-4 system s= pec describes the differences between "regular" ECMA scipts and &= quot;MPEG-4 scripts". As far as I understand these constraints do not = allow dangerous ECMA script constructs, which means there is no need for an= ECMA script security model in this context. Below I attached the MPEG-4 an= nex that describes the differences.
I suggest to resolve this as follows= :
a) replace in section 5 "securi= ty considerations" all current references to ECMAScript by MPEG-4 scri= pt, and
b) add to the fifth paragraph (start= ing with "In ISO/IEC 14496-1 a security model is defined for ..."= ) the following trailing sentence "Note: MPEG-4 scripts are based on E= CMA scripts, but there is no need for an ECMA script security model, as the= use of insecure ECMA  script constructs is impossible in MPEG-4 scrip= ts."

3) 2.4:  Why is this form of a= pplication-level fragmentation better than
  IP fragmentation?
This is because of error resilience.= If IP fragmentation occurs without application-level fragmentation, then a= ll data of the entire Access Unit gets lost when one such fragmented IP pac= ket is lost. When application-level fragmentation is used, and one RTP pack= et with an AU fragment gets lost, then the received RTP packet(s)  wit= h the other AU fragments can still be decoded. I suggest to remove "so= as to avoid IP layer fragmentation" from the first sentence of sectio= n 2.4, and to add the following after the first sentence: "Hence when = an IP packet is lost after IP-level fragmentation, only an AU fragment may = get lost instead of the entire AU".

Any comments very welcome.


Best regards,

Jan van der Meer

*******begin of MPEG-4 system annex*= ******

        MPEG-4 Scripts Have a Rigid Representa= tion  
MPEG-4 scripts differ slightly from ECMA = scripts. The most important difference is that MPEG-4 scripts are not repre= sented textually, but are transmitted as a parse tree representation.  = ;This means that only constructs that can be represented by the MPEG-4 pars= e grammar can be encoded and transmitted. Not all ECMA script constructs ca= n be represented in MPEG-4 scripts.

The differences between ECMA scripts and s= cripts that can be represented in MPEG-4 are given below.


        Keywords
MPEG-4 scripts cannot utilize the followi= ng keywords: catch delete do fin= ally in instanceof throw try typeof void with .

This means that  do – loops and  for= – in loops are not p= ossible.

        Relational operators

The relational operators  "=3D=3D=3D" and "!=3D=3D" cannot be included in MPEG-4 Scripts.

        Labeled statements

In MPEG-4 scripts it is impossible to labe= l statements and to break= or to labeled statements.

        Switch statement restriction

MPEG-4 scripts with switch statements= can only take numerical case expressions and always must have at leas= t one case statement.

In particular this means that

switch {

        case (x+= 1):  ….

}

is not possible, while

Switch {

        case 1: =  ….

}

is okay.

        Functions, not programs

The MPEG-4 event driven script model allow= s only functions to be called in response to events.

        Expressions

Statements that include statement blocks, = such as for are represented in the parse tree as having an empty statement = block, where as in ECMA script they can omit this block. Functionally, the = statements behave identically. For example, the expression:

        for ( <expr>; <expr>; &l= t;expr>)

must be represented as


        for ( <expr>; <expr>; &= lt;expr>) {}

        = Array and Object Literals
Array and object literals of the form [value1, value2, .., = valueN] and {property1:value1, property2= : value2, .. propertyN:valueN} cannot be used in MPEG-4 scripts.

*******end of MPEG-4 system annex****= ***











Allison Mankin <mankin@psg.com= >

2003-06-27 06:19 AM
Please respond to mankin

       
        To: &nbs= p;      Jan vanderMeer/EHV/CE/PHILIPS@EMEA3
dmackie@apple.com
viswanathan.swaminathan@sun.com
singer@apple.com
Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1
        cc: &nbs= p;      casner@acm.org
magnus.westerlund@ericsson.com
csp@csperkins.org
smb@research.att.com
ned.freed@mrochek.com
mankin@psg.com
avt@ietf.org
        Subject:=        IESG Review of draft-ietf-avt-mpeg4-simple-07.t= xt - Discuss Comments

        Classific= ation:        




The IESG reviewed draft-ietf-avt-mp= eg4-simple-07.txt and had a few concerns
that should be addressed before the draft can advance.  Editorially:
  Comment:  It is strange to have more than one section labeled<= br>  "Introduction."  Please pick a new label for section = 2.1.

Steve Bellovin and Ned Freed both request that a reference be given in
the Security Considerations for security model for ECMAscript.  Here is Steve's Discuss comment:

  Where is the security model defined for ECMAScript in this context?=  
  (Problems with the model have been part of the Javascript security =
  problem for Web browsers.)

Steve also asked:

  2.4:  Why is this form of application-level fragmentation bett= er than
  IP fragmentation?

Please discuss the issues in email and we'll see if the fixes to the draft<= br> can be done as notes rather than a revised i-d, to be quicker.

Allison

--=_alternative 005C46FCC1256D59_=-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt