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

From: "Even, Roni" <[email-masked]>
Date: Mon, 27 Jun 2005 16:53:41 +0300

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,

I have some comments on the draft:

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

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

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.

Roni: I tried to make it short based on Colin's comment. But I can make
it more in line with you comment.

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.

Roni: I assume that this is a general comment applicable to all medi
type registration. So if there is are guidelinesI would follow them.

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.

Roni: OK, so the right way is with space. 

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

Roni: I will do it, does this apply to all media type registerations?

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.

Roni: OK

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.

Roni: OK

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.

Roni: I will change to SHALL. As for the profile I can only refer to
current profiles, I will add a sentence like "any applicable RTP profile
(e.g., [RFC3551])"

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.

Roni: Thanks, the default in annex Q is 4800, I will fix it.

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.

Roni: OK

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.

Roni: OK

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.

OK

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: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Jun 2005 16:10:39 +0200

Hi Again,

Some few replies and a correction.

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

I am expecting to find Form Feed (0x0C) between each page, however your 
is lacking them. Either they are not produced or the submission process 
results in them being stripped.

> it more in line with you comment.

I don't suggest anything extensive, simply something that clarifies what 
the media type really is for.

> type registration. So if there is are guidelinesI would follow them.

Unfortunatly we are a bit short on these general guidelines.

> Roni: I will do it, does this apply to all media type registerations?

Yes, at least for RTP payload format media types.

>          partially contains binary data.

Sorry, I copied this from the 3GPP timed text draft and you should 
remove "partially" unless H.224 is text based protocoll.

> current profiles, I will add a sentence like "any applicable RTP profile

Good.

> Roni: Thanks, the default in annex Q is 4800, I will fix it.

Good then no problem.

Cheers
-- 

Magnus Westerlund

---

From: Tom Taylor <[email-masked]>
Date: Mon, 27 Jun 2005 14:27:56 -0400

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

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