[Council] Minutes 2011-03-23
stpeter at stpeter.im
Tue Apr 12 17:08:08 UTC 2011
On 4/5/11 1:19 PM, Matthew A. Miller wrote:
> Thanks for the reminder (-:
> Overall, it looks pretty good.
> Some nits:
> * In "2. Terminology"; it states "For example, during a Jingle
> negotiation the Jingle Initiator might first take on the role of an
> S5B Requester but if that first bytestreams negotiation fails then
> the Jingle Responder might take on the role of an S5B Requester."
> One of those S5B Requesters should be a S5B Target, no?
No, this describes the fallback scenario. However, it might be clearer as:
For example, during a Jingle negotiation the Jingle Initiator might
first take on the role of an S5B Requester (with the Jingle Responder
being the S5B Target) but if that first bytestreams negotiation fails
(the so-called "fallback scenario") then the Jingle Responder might take
on the role of an S5B Requester (with the Jingle Initiator being the S5B
> * In "4. Discovering Proxies"; the "host" parameter allows for either
> an IP address or a hostname. However, there are some conventions for
> representing IPv6 addresses in strings (e.g.
> "[3ffe:1900:4545:3:200:f8ff:fe21:67cf]"). I think this text should
> indicate what's expected when an IP address is specified (e.g. MUST
> be the address without additional formatting, e.g
I think that following RFC 5952 would be good here (since that is what
we do in RFC 6120 and elsewhere). Fixed in my working copy.
> * In "9 Formal Description"; there is no mention of <udpsuccess/> as
> there is of the other elements in the schema. I don't know how much
> it really matters, but I tend to favor consistency (-:
Fixed in my working copy.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
More information about the Council