On Tue, 2009-06-09 at 23:12 +0200, ext Robert Sparks wrote: > I'm going through -07 in detail now to figure out the next step, and > just went back > through the email threads to make sure nothing got dropped. > > I think we still have a rough edge related to what's below (and I > don't understand Jari's response > now that I've read the draft carefully). > Sorry, i did not read the text that carefully (rather only Dean's question)
My previous comment was about the default mode if client won't give any. In 04 it was "xcap-patching" but it can be any of those, and Dean proposed "no-patching" which is fine. > My read is that the default was intended to be the simplest (and > required to implement) mode of > "no-patching" and that we just had a single typo in the first > paragraph of section 4.3. The last > sentence in that first paragraph should say "no-patching" rather than > "xcap-patching" and > the conflict that Dean points to below is resolved. > > RjS > Right, the last sentence in 4.3 is _wrong_. The subscribers MAY implement any of the modes, but it doesn't need to support patching at all. The same applies to the notifier with the exception that it MUST implement xcap-component subscriptions. The last sentence of the first chapter of 4.3 is also wrong since the client could only subscribe to xcap component changes, so it'd better to remove the last part ", as all subscribers are required to support that mode." br, jari _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement...@cs.columbia.edu for questions on current sip Use sipp...@ietf.org for new developments on the application of sip
