[AVT] RE: draft-ietf-avt-rtp-jpeg2000-03.txt

["Edwards, Eric" <Eric.Edwards@am.sony.com>]

Dear Colin and all,

Sorry for the delay.  Unfortunately, my Sony colleagues and I are tied up
for the next few weeks.  So, we will not be able to make all necessary
updates to the jp2/rtp draft for the Vienna meeting. We should be able to
post an updated version in about two weeks.

As to your questions, my colleague has forwarded these answers - 

> 
>  - Section 5.1 seems to imply that JPEG 2000 error resilience markers are
>    only used with non-intelligent packetization. Is this correct? Are the
>    error resilience markers not useful if the JPEG stream is intelligently
>    packetized?

The first sentence is not true.

In non-intelligent packetization, a serious quality distortion will be 
occured without JPEG 2000 error resilience markers, 
but it does not imply that error resilience markers are only used 
with non-intelligent packetization. 

The error resilient markers are also useful with intelligent 
packetization.


>  - Is non-intelligent packetization a requirement? The situations where it
>    will be useful seem very limited.

Non-intelligent packetization is not always required (optional) at a sender,

but is required at a receiver.

It is true that the situations where non-intelligent packetization will 
be used are limited, but a receiver who received the non-intelligent 
packets must process the packets properly. 

>  - The extension mechanism in Section 8 is not used. I suggest removing it

>    and marking the X bit in the payload header as "reserved". 

We agree.  -> it is an item to change in the next version.

>  - The second paragraph of Section 9 is not appropriate, since the payload
>    format cannot specify the type of video content to be transported. Are
>    there no ways in which a malicious sender can disrupt the receiver?

It is entirely correct.
I will refer to other drafts and find the better expressions.

>  - In addition to the MIME type registration, the draft should include a 
>    description of how the MIME type is mapped to SDP (Section 8.2 of the
>    H.264 payload format is a good example).

We agree.  -> it is another item to change in the next version.


>  - Section 10 may be better written as an informative appendix? 

We agree.  -> it is also an item to change in the next version.

>  - It may be useful to include some examples, showing the complete packets
>    with all headers and data (including the RTP headers).

We agree. -> it is also an item to change in the next version



I will proof-read for clarity before we post the next draft.

Best regards,

Eric



-----Original Message-----
From: Colin Perkins [mailto:csp@csperkins.org]
Sent: Tuesday, July 08, 2003 10:28 AM
To: Edwards, Eric
Cc: avt@ietf.org; casner@acm.org; magnus.westerlund@ericsson.com
Subject: Re: draft-ietf-avt-rtp-jpeg2000-03.txt


Eric,

--> "Edwards, Eric" <Eric.Edwards@am.sony.com> writes:
> The Internet-Draft - draft-ietf-avt-rtp-jpeg2000-03.txt - has been
> posted.  
> 
> Some time passed before this version was submitted.  Most of the time was
> spent discussing if potential reconciliation with work that was taking
> place in ISO/IEC JTC1 SC 29 WG 01 (JPEG) was in order.  After lengthy
> discussions it was agreed by the experts in WG 01 that there were
> different goals and application areas targeted for our respective work
> and that the JP2/RTP proposal (draft-ietf-avt-rtp-jpeg2000-03.txt) should
> move forward in IETF as is.  
> 
> So at this stage we are ready to move to Last Call if the AVT experts
> have no objections to the current draft.  
> 
> Please advise and comment.

I have a number of comments with regards to this draft:

 - Section 5.1 seems to imply that JPEG 2000 error resilience markers are
   only used with non-intelligent packetization. Is this correct? Are the
   error resilience markers not useful if the JPEG stream is intelligently
   packetized?

 - Is non-intelligent packetization a requirement? The situations where it
   will be useful seem very limited.

 - The extension mechanism in Section 8 is not used. I suggest removing it 
   and marking the X bit in the payload header as "reserved". 

 - The second paragraph of Section 9 is not appropriate, since the payload
   format cannot specify the type of video content to be transported. Are
   there no ways in which a malicious sender can disrupt the receiver?

 - In addition to the MIME type registration, the draft should include a 
   description of how the MIME type is mapped to SDP (Section 8.2 of the
   H.264 payload format is a good example).

 - Section 10 may be better written as an informative appendix? 

 - It may be useful to include some examples, showing the complete packets
   with all headers and data (including the RTP headers).

I would also urge a careful proof-reading of the draft for both quality of
English, clarity of specification, and appropriate use of the requirements
language in RFC 2119. 

-- 
Colin Perkins
csp@csperkins.org

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt