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

[Magnus Westerlund <[e-mail]>]

Hi Again,

Some few replies and a correction.

Even, Roni wrote:
> 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.

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.

> 
> 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.

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

> 
> 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.

Unfortunatly we are a bit short on these general guidelines.

> 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?

Yes, at least for RTP payload format media types.

> 
> 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

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


> 
> 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])"

Good.

> 
> 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.

Good then no problem.

Cheers
-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]

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