[itu-sg16] Progressing work in Q2/16

Paul E. Jones paulej at packetizer.com
Sat Aug 8 23:37:50 EDT 2009


Sébastien,

Thanks for doing that for us.  Hopefully, this will mean we will not find a
need to introduce any corrections via the Implementers' Guide.

I trust the H.225.0 editor (copied) will address the editorial issue.

Paul

> -----Original Message-----
> From: sebastien.castano at itu.int [mailto:sebastien.castano at itu.int]
> Sent: Wednesday, July 29, 2009 8:50 AM
> To: paulej at packetizer.com
> Cc: itu-sg16 at lists.packetizer.com; Stephen.Botzko at polycom.com;
> mperumal at cisco.com; anparvee at cisco.com; s.horne at packetizer.com;
> olivier.dubuisson at orange-ftgroup.com
> Subject: RE: [itu-sg16] Progressing work in Q2/16
> 
> 
> Dear Paul,
> 
> I checked ASN.1 modules in H.323v7 and H.225.0v7 as asked by Olivier and
no
> error were depicted.
> 
> Just a small editing issue in H.225.0v7 in the comments inserted in
> ServiceControlDescriptor definition:
>   A return line is missing between "-- referenced " and "--
protocol/resource"
> 
> Best regards,
> Sébastien Castano
> 
> 
> 
> 
> > -----Original Message-----
> > From: Paul E. Jones [mailto:paulej at packetizer.com]
> > Sent: vendredi, 24. juillet 2009 18:28
> > To: 'Olivier DUBUISSON'
> > Cc: itu-sg16 at lists.packetizer.com; Castano, Sebastien;
> > 'Botzko, Stephen'; 'Muthu ArulMozhi Perumal (mperumal)';
> > 'Anisha Parveen'; 'Simon Horne'
> > Subject: RE: [itu-sg16] Progressing work in Q2/16
> >
> > Olivier,
> >
> > Thanks for your careful review.  I have copied the respective
> > editors so that they can address these points in their documents.
> >
> > Editors: Simao requested that we not make the with respect to
> > the way we reference ITU-T Recommendations in H.225.0 and
> > H.323, since that would produce a lot of change marks that
> > are not technical changes.  However, for H.460.geo (and
> > H.460.23/24), we should make references according to this guidance.
> >
> > With respect to H.323 and BER/PER references, the only
> > reference to BER (as far as I know) is one of the Annex M.x
> > sections.  There, we do not encode or decode messages, but
> > merely provide a tunneling mechanism for protocols defined
> > elsewhere.  As such, I would think we might want an
> > informative reference to BER.
> >
> > I'll be out of the office next week, so I might be slow in
> > responding to any replies.
> >
> > Paul
> >
> > > -----Original Message-----
> > > From: Olivier DUBUISSON
> > [mailto:olivier.dubuisson at orange-ftgroup.com]
> > > Sent: Friday, July 24, 2009 9:43 AM
> > > To: Paul E. Jones
> > > Cc: itu-sg16 at lists.packetizer.com; Sébastien Castano
> > > Subject: Re: [itu-sg16] Progressing work in Q2/16
> > >
> > > Paul,
> > >
> > > here are some editorial changes:
> > >
> > > * H.323v7:
> > > - it is better to remove the whitespace in front of each opening
> > > parenthesis in an OID as it makes it easier to understand when a
> > > number is associated with an identifier and avoid any
> > confusion in the
> > > case a number without an associated identifier is followed
> > by a number
> > > (a possible case)
> > > - clause 2: Add a reference to the ITU-T X.680 series as well as to
> > > X.690 and X.691 since both BER and PER are mentioned; I see a
> > > normative reference to X.680 in Annex R: This is unusual!
> > > - clause 4: OID is not defined as an acronym for Object-Id (I would
> > > prefer not to use that acronym throughout the text, though!)
> > > - Clause M4.5.3: Add an OID to the ASN.1 module; is this the only
> > > ASN.1 module in that standard?
> > > - M5.3: 'i' missing in OBJECT IDENTIFIER in the first sentence
> > >
> > > * H.225.0v7:
> > > - Clause 2 doesn't reference the latest edition of the
> > X.680 and X.690
> > > series
> > > - Annex H: Add an OID to the ASN.1 module
> > > - Table VI.1: remove leading zeroes within icd-ecma(0012)
> > > - it is also better to remove the whitespace in front of
> > each opening
> > > parenthesis in an OID as it makes it easier to understand when a
> > > number is associated with an identifier and avoid any
> > confusion in the
> > > case a number without an associated identifier is followed
> > by a number
> > > (a possible case)
> > >
> > > * H.460.geo:
> > > - Clause 2: replace "ISOC/IETF" with "IETF"
> > >
> > > * General remark:
> > > As approved by TSAG last year, the new way of referencing an ITU-T
> > > Recommendation is "Recommendation ITU-T H.xxx" in clause 2
> > and "ITU-T
> > > H.xxx" as a reference in the body.
> > >
> > > I am Cc'ing Sébastien Castano from the TSB in case he can find some
> > > time to check the ASN.1 modules in H.323v7 and H.225.0v7.
> > > --
> > > Olivier DUBUISSON, ITU-T ASN.1 & OID Project leader France Telecom
> > > NSM/RD/DDEV - BP 50702 - 22307 Lannion Cedex - France
> > > tel: +33 2 96 05 38 50 - fax: +33 1 58 15 52 05
> > >
> > >
> > > Paul E. Jones wrote:
> > > > Q2/16 Experts,
> > > >
> > > >
> > > >
> > > > There are several draft documents that are scheduled for
> > consent at
> > > > the October/November 2009 meeting in Q2.  They are:
> > H.323v7, H.323
> > > > Annex I (use of new FEC procedures defined in the IETF),
> > H.225.0v7,
> > > > H.460.geo (transmission of geographic information in H.323),
> > > > H.460.23 (NAT determination), and H.460.24
> > (point-to-point media flow through NAT).
> > > >
> > > >
> > > >
> > > > Pointers to the current editors' draft documents can be
> > found here:
> > > >
> > > > http://www.packetizer.com/ipmc/h323/doc_status.html
> > > >
> > > >
> > > >
> > > > I would like to kindly request that you give these documents a
> > > > thorough review and do one of two things:
> > > >
> > > > 1)      Submit a contribution to the next SG16 meeting
> > proposing changes
> > > > to these texts
> > > >
> > > > 2)      Provide your comments via the list or directly to
> > the editor;
> > > > the editor will address any minor editorial issues in the
> > text and
> > > > prepare a contribution for technical changes (if necessary)
> > > >
> > > >
> > > >
> > > > I want to keep these documents on schedule, so your input and
> > > > comments would be very helpful.
> > > >
> > > >
> > > >
> > > > Of course, if you have any questions or comments, I am more than
> > > > happy to provide input.
> > > >
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Paul E. Jones
> > > >
> > > > Rapporteur, ITU-T Q2/16
> > >
> >
> >
> >
> >
> 





More information about the sg16-avd mailing list