-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
More questions, comments and nits:
A.13. Section 5.3.1.1 "...ResourceIds are variable length, up to 255 bytes (2048
bits)..."
Because Destination has a length field defined as an uint8 that effectively
limits the size of DestinationData to 255 bytes, and because ResourceId is
prefixed by one byte indicating the length, the ResourceId length is limited to
254 bytes, or 2032 bits.
A.14. Section 5.3.2 "uint32 length;"
I can assume that this length covers the Header, MessageContents and Signature,
but I would guess that this was useful when Message was sent without
FramingHeader over TCP (same than for the relo_token used to disambiguate STUN
packets). Now that this is useless, can't this length been only Header and
MessageContents, so it is possible to find the boundary between MessageContents
and Signature without having to parse MessageContents at all?
A.15. Section 5.3.4 "HashAlgorithm hash_alg;"
What are the algorithms that should be supported?
Is the hash only used to identify the certificate in SecurityBlock.certificates?
Also the text says that "[t]he certificate_hash contains the hash of the
certificate object." Are we talking about the hash of the DER encoded
certificate, as stored in GenericCertificate.certificate?
A.16. Section 5.5.1.1. "IceCandidate candidates<0..2^16-1>;"
Because there must be at least one candidate, should this be:
IceCandidate candidates<1..2^16-1>;
A.17. "config_data (type==config)"
The definition of this field is "[t]he contents of the configuration document",
but 10.1 says that a file "...can contain multiple 'configuration' elements...".
So should not this field be in fact defined as "One XML configuration
production. This MUST be encoded with UTF-8 and assume a default namespace of
...", like for the kinds value? And in this case what about the signature
element in the XML fragment?
A.18. Section 5.6.2 "...not all aspects of the header apply to both types of
transports."
It would be great if this could be explained a little bit more. For example I
assume that on a reliable link, the receiver still need to send the Ack for each
frame received (to calculate the RTO), but what about the content of the
ack_sequence and received fields?
A.19. Section 5.6.3.1.1, last paragraph
This paragraph described a lockstep algorithm, but if it is the case then there
is no need for the received field, as we would always know that the previous
messages have been received.
A.20. Section 5.7, "If the message is not fragmented, then both the first and
last fragment are set to 1..."
If the first fragment bit is set to 1 when the message is fragmented and is also
set to one when the message is not fragmented, then it is always set to 1, so
what is the point of having it in the first place?
A.21. Section 10.1. "<kind name='sip-registration'><data-model>..."
Why do we need to repeat the data-model and access-control that were already in
the IANA registry? Or is it a way to override the IANA definitions as the
example would suggest? (as the registration for SIP-REGISTRATION is using
DICTIONARY and USER-NODE-MATCH).
A.22. Section 10.1. "sequence: a monotonically increasing sequence number
between 1 and 2^32"
According to section 5.3.2 and 5.3.2.1, it should be between 0 and 2^16-2
(65534).
A.23. Section 10.1. "root-cert This element..."
I guess that the encoding to use is base64, but it is said nowhere.
A.24. Section 10.1.1. "| attribute id { xsd:int }),"
Does not match 13.6, that is saying that this is an unsigned integer. Should
probably use xsd:unsignedInt instead.
Note that there is other places in the RELAX NG document where the type can be
improved (initial-ttl, etc...)
A.25. Section 10.1.1. 'access-control-type |= "user-match-with-anon-create"'
This control type is never defined in the document.
A.26. Section 10.1.1. 'kind-names |= "sip-registration"'
the sip-registration kind is not defined in this document. OTOH,
certificate-by-node and certificate-by-name are defined, but not listed here.
A.27. Section 10.1.1. 'self-signed-digest-type |= "sha1"'
Section 10.1. says that '[v]alid values for this parameter are "SHA-1" and
"SHA-256"'.
A.28. Section 10.1.1 last paragraph "such an XML configuration file sent over
email."
Because the signatures on the XML document are done on exact byte string and
because emails servers are known to mess with end of lines, we will see
configuration documents that cannot be verified after been sent by email (what
was wrong with using XML-sig anyway?).
A.29. Section 13.15 "destination: a hex-encoded Destination List object"
A Destination List object is never formally defined in the whole document, so is
it just Destination objects packed together, or is it in fact a "Destination
destination_list<0..2^16-1>" ? In other words, does it start with a length
field?
Nits:
- ----
- - Section 5.7 After "Where these values are:"
s/resource/resource_id/
- - Section 6.4.1.2. "...that the storing peer is not require to perform this
verification."
s/require/required/
- --
Marc Petit-Huguenin
Personal email: [email protected]
Professional email: [email protected]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkz9X8sACgkQ9RoMZyVa61db8wCfY920Y+l8ho7H6crmx+Bwbczi
VOMAn2jqKBSRaf96sNh1P0L34debXb96
=/8Wr
-----END PGP SIGNATURE-----
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
