On 12/12/12 2:13 PM, Alexey Melnikov wrote:
On 04/12/2012 18:16, Flemming Andreasen wrote:
Hi Alexey,
Hi Flemming,
Thank you for your review of the document - comments below:
On 11/26/12 7:03 AM, Alexey Melnikov wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-mmusic-sdp-media-capabilities-15
Reviewer: Alexey Melnikov
Review Date: 2012-11-26
IETF LC End Date: 2012-11-12
IESG Telechat date: not scheduled
Summary: This document is ready for publication as Proposed Standard,
with nits.
Nits/editorial comments:
This might be obvious to a SIP implementer, but the media
type/subtype definition RFC is not referenced anywhere. Should it be?
I don't believe so. The document is an extension of SDP (RFC 4566)
which maintains its own media type name space and registry and hence
it simply follows the rules of SDP (as defined in RFC 4566, which did
change from the old SDP spec defined in RFC 2327).
RFC 4288 (which I presume you are referring to here) should not apply.
I think SDP has to be in agreement with RFC 4288 or we have a bigger
problem. In particular media type syntax. But I am Ok with no change
in this area.
3.3.5. The Latent Configuration Attribute
Latent configurations may be announced by use of the latent
configuration attribute, which is defined in a manner very
similar to
the potential configuration attribute. The latent configuration
attribute combines the properties of a media line and a potential
configuration. The media type (mt=) and the transport protocol(s)
(t=) MUST be specified since the latent configuration is independent
of any media line present. In most cases, the media configuration
(m=) parameter MUST be present as well (see Section 4 for examples).
This doesn't look like a correct use of MUST, please reword not to
use any RFC 2119 keyword or at least provide a pointer to a document
that contains the original requirement.
How about this:
<quote>
Latent configurations may be announced by use of the latent
configuration attribute, which is defined in a manner very
similar
to the potential configuration attribute. The latent
configuration
attribute combines the properties of a media line and a
potential
configuration. A latent configuration MUST include a media
type (mt=) and a transport protocol configuration parameter
since the latent configuration is independent
of any media line present. In most cases, the media
configuration
(m=) parameter needs to be present as well (see Section 4
for examples).
</quote>
Yes, this is exactly what I had in mind. Thanks.
The lcfg attribute is a media level attribute.
[...]
If a cryptographic attribute, such as the SDES "a=crypto:" attribute
[RFC4568], is referenced by a latent configuration through an acap
attribute, any keying material required in the conventional
attribute, such as the SDES key/salt string, MUST be included in
order to satisfy formatting rules for the attribute. The actual
value(s) of the keying material SHOULD be meaningless, and the
Can you please elaborate on what are you trying to say here?
Is this better:
<quote>
If a cryptographic attribute, such as the SDES "a=crypto:"
attribute [RFC4568], is referenced by a latent
configuration through an acap attribute, any keying material
required in the conventional attribute, such as the SDES
key/salt
string, MUST be included in order to satisfy formatting
rules for
the attribute. Since the keying material will be visible
but not actually used at this stage (since it's a latent configuration),
the value(s) of the keying material SHOULD be meaningless, and
the receiver of the lcfg attribute
MUST ignore the values.
</quote>
This is better. I was actually most wondering about the meaning of
"meaningless". Did you mean "not a real value you would use for a real
exchange"?
Indeed - much better stated that way. I've updated the text accordingly
and just submitted the updated document. Thanks again for the review and
comments.
Regards
-- Fleming
receiver of the lcfg attribute MUST ignore the values.
.
Best Regards,
Alexey
.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
