Subject: [AVT] Comments on draft-ietf-avt-mime-h224-02.txt

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Jun 2005 14:43:19 +0200

Hi Roni,

I have some comments on the draft:

1. First, it is quite irritating that the draft lacks the correct page 
break markers.

2. Section 1, Introduction

I think the introduction could be clarified to better explain:
- The media type is for H.224 over RTP, with packetization according to 
Annex Q of H.323.
- FECC is the only real usage of H.224, however the protocol is not 
limited to FECC.

Another comment is that media type registrations are done to not be 
limited to SDP. However other protocols like SDP-NG or FOO would need to 
specify a mapping. Therefore I have some problems with the usage of 
SDP-based. However I do not have a better proposal.

Due to this I would prefer to have some attempt to improve the 
introduction for clarity.

3. On a number of places there is missing spaces between the text and 
the brackets ([ or ]) for the references.

4. Section 4. I think you should clarify that this registration is also 
in accordance with RFC 3555.

5. I am missing the "Restrictions on usage:"
entry. I would suggest that you use the following text:

         This media type depends on RTP framing, and hence is only
         defined for transfer via RTP [3]. Transport within other framing
         protocols is not defined at this time.

6. The encoding consideration should be clarified to indicate what type 
of data this is. Again I think the following text would be appropriate 
to add.

         This media type is framed (see section 4.8 in [31]) and
         partially contains binary data.

7. Section 5. First bullet:
"The media name in the "m=" line of SDP MUST be application.  The
    transport SHOULD be RTP and the payload type is dynamic."

I have two questions here. First is why it is only a SHOULD in regards 
to RTP. To me this media type is defined for RTP only and can with 
defined transport only be used with RTP. Usage of another transport than 
RTP would require explicit signalling. Secondly wouldn't it be better to 
discuss also profiles? There should be no limitations when it comes to 
profiles, but as it is the combination of RTP and profile etc it might 
be appropriate to mention this.

8. Section 5, third bullet:
The clock rate in the "a=rtpmap" line MUST be 0.

Here I see a serious problem. RTP needs an clock rate, 0 is not a valid 
value here. Is there a clock rate defined when using annex Q or is it 
media dependent.

9. Section 6, first paragraph.
    RTP packets using the payload format defined in this specification
    are subject to the security considerations discussed in the RTP
    specification [RFC3550].

I prefer the extended sentence that discusses profiles also:

    RTP packets using the payload format defined in this specification
    are subject to the security considerations discussed in the RTP
    specification [RFC3550] and any applicable profile, e.g. RFC 3551 or
    RFC 3711.

10. Section 6. I am missing a discussion on the security sensitivity of 
the H.224 content of the RTP packets. As H.224 contains a negotiation 
protocol it seems it would be very sensitive to attacks. Also rouge 
control of the camera may need to be discussed. I think this should be 
used as motivation for using authentication and integrity protection.

11. Section 7. I think it might be best if all the MIME registration 
related references are informal: RFC 3555, RFC 2048 and Freed's draft.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 28 Jun 2005 08:54:01 +0300

Hi,
I used XML2RFC 1.29
Roni 

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]] 
Sent: Monday, June 27, 2005 9:28 PM
To: Even, Roni
Cc: Magnus Westerlund; IETF AVT WG; [email-masked]
Subject: Re: [AVT] RE: Comments on draft-ietf-avt-mime-h224-02.txt

I produce XML2RFC documents with the web tool on a PC, and normally
check them afterward with a hex editor to make sure line and page ends
are set up correctly.  I failed to do so with 2833bis-09 because XML2RFC
release notes said they had fixed the tool to provide for Windows
line-end conventions.  I see now I was mistaken: the document begins as
usual in the past with a series of LF (x'0a') rather than CR-LF
(x'0d0a') as required by IETF formatting conventions.  Similarly the end
of page is marked by LF-FF-LF (x'0a0c0a'), an improvement in ordering
over previous versions, but lacking the CRs.

When I look at draft-ietf-avt-mime-h224-02.txt, I'm surprised to see no
form feed characters at all!  There's just a pair of LF characters at
the end of the page.

I'm copying Marshall Rose on this note.  The problem may be intractable,
but the ideal output of the tool (according to RFC 2234) would be:

CR-LF for line ends
CR-LF-FF-CR-LF between pages

Even, Roni wrote:
> Magnus,
> Thanks for going over the document.
> In line
> Roni
> 
> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Monday, June 27, 2005 3:43 PM
> To: Even, Roni; IETF AVT WG
> Subject: Comments on draft-ietf-avt-mime-h224-02.txt
> 
> Hi Roni,
> 

> break markers.
> 
> Roni: I am using xmk2rfc so it is a bit strange, can you show me an 
> example.
> 
...

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 30 Jun 2005 08:53:22 +0300

Tom,
After looking at my original and sendint it from my hotmail account, the
conclusion is that the form feed are removed by hotmail when attaching
the document. I will try to submit next time from my company exhange
server though in the past they had problem with the attachement

No problem in XML2RFC

Roni 

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]] 
Sent: Monday, June 27, 2005 9:28 PM
To: Even, Roni
Cc: Magnus Westerlund; IETF AVT WG; [email-masked]
Subject: Re: [AVT] RE: Comments on draft-ietf-avt-mime-h224-02.txt

CR-LF for line ends

...