Hi, I reviewed the latest version -15 now: Sec. 3.1:
"Note that the registration lifetime known from the regular SIP REGISTER method is inherited from the lifetime attribute of the basic RELOAD StoredData structure (see Section 7 in [RFC6940])." Not sure that it's expressed in the right order. Maybe better: Note that the lifetime attribute of the basic RELOAD StoredData structure (see Section 7 in [RFC6940]) now corresponds to the registration lifetime given by a regular SIP REGISTER method in the "expires:" parameter. Sec. 5.1. "Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted SIP messages over the connection as in normal SIP." I find this still confusing as there is no way to send "plain" SIP messages via RELOAD, they will always be sent via an encrypted (D)TLS transport from end-to-end. Maybe: Once the AppAttach succeeds, the peer sends SIP messages (for SIP and SIPS sessions) over the connection as in normal SIP. It is noteworthy that according to [RFC6940] all overlay links built by AppAttach are utilizing (D)TLS secured transport. (then delete the redundant: It is noteworthy that according to [RFC6940] all overlay links are built on (D)TLS secured transport.) Similarly: "While hop-wise encrypted paths do not prevent the use of plain SIP, SIPS requires end-to-end protection that may include client links and endpoint certificates." Since every AppAttach Link will be end-to-end protected by (D)TLS, I think this statement is superfluous. >> Sec. 6: >> GRUUs in RELOAD are constructed by embedding a >> base64-encoded destination list in the gr URI parameter of the GRUU. >> >> I guess that the destination list is encoded in the same way as >> described in section 6.3.2.2. of RFC 6940. Simply a list of >> Destination entries without any preceding length field?! >> > > Well yes, we're using the RELOAD destination list (term and definition) here. > The above encoding describes the URI-encoding, not the representation of the > data structure in the overlay. That at least caused an ambiguous interpretation on my side. I thought that I need to build the binary representation of the destination list data structure first and then encode it in base64. This is obviously wrong and should be clarified. Regards, Roland _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
