Subject: [Sip] callerprefs: Various

From: Ben Campbell <[email-masked]>
Date: 21 Apr 2003 17:18:22 -0500

Here is the beginning of my review of draft-ietf-sip-callerprefs-08.txt.
Adam and Cullen's approach of separating major issues in SIMPLE seemed
to work well, so I will follow the same approach here. This email talks
about nits and typos. I will send a separate note for each issue that I
think might warrant discussion.

------------------------------------

Inclusion of summary of feature tag concepts: While I appreciate this
convenience, it always worries me to copy or summarize
normative text from another document. In the event of a conflict between this summary
and the referenced text, who wins? Surely it is the referenced text--but implementers may
attempt to implement this without reading that text. (It is bad enough when people
try to implement examples rather than specification)

6.1p4: 

6.1 Register Example: The example is inconsistent on whether a boolean tag has an explicit "true/false"
value, or simple exists. I do not understand the semantic difference between the two syntaxes.

7.4p8 - missing word: ...predicate [in] the contact's matching set.

7.4p8&9 (and surrounding) - This is pretty hard to digest. Listing it stepwise might help.

7.4p15 : s/prefentially/preferentially

12p3: So, if I do a query register, would I expect to get back the feature sets contained in any
registered contacts? If so, then worrying about protecting it in the original request does not seem
particularly useful.

16 ref 3: Is this really a normative reference? Also, no author listing.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Apr 2003 10:15:56 -0400

> value, or simple exists. I do not understand the semantic difference between the two syntaxes.

It is simply that '="TRUE"' is the default value if none is provided. It 
provides a bit of conciseness for a common case. Maybe some explanatory 
text is in order, somewhere.

> registered contacts? If so, then worrying about protecting it in the original request does not seem

Even query registers can (and probably should) be access controlled. So 
protecting still makes sense to me.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 Apr 2003 02:24:45 -0400

Ben,

Thanks for the comments. Responses inline.

Ben Campbell wrote:
> Here is the beginning of my review of
> draft-ietf-sip-callerprefs-08.txt. Adam and Cullen's approach of
> separating major issues in SIMPLE seemed to work well, so I will
> follow the same approach here. This email talks about nits and typos.
> I will send a separate note for each issue that I think might warrant
> discussion.
> 
>  convenience, it always worries me to copy or summarize normative
> text from another document. In the event of a conflict between this
> summary and the referenced text, who wins? Surely it is the
> referenced text--but implementers may attempt to implement this
> without reading that text. (It is bad enough when people try to
> implement examples rather than specification)

On the other hand, people have complained to me that the spec is
incomprehensible without some kind of background, and rfc2533 itself is
too long and complex, and too far outside of the sip universe, to be
easily digestable by a sip implementor. I would rather that the caller
prefs spec be understandable. I'll add a note that says in the event of
conflict, rfc2533 wins of course. The intro to the tutorial now reads:

> This section provides a brief overview of RFC 2533 and related 
> specifications that form the content negotiation framework. This 
> section does not represent normative behavior. In the event of any 
> conflict between the tutorial material here and the normative text in
>  RFC 2533, RFC 2533 takes precedence.

> 
> 6.1p4:
> 
> 6.1 Register Example: The example is inconsistent on whether a
> boolean tag has an explicit "true/false" value, or simple exists. I
> do not understand the semantic difference between the two syntaxes.

I'm confused. Section 6.1 paragraph 4 has nothing to do with boolean 
tags. Its talking about the absence of feature tags entirely, not the 
absence of a VALUE for a feature tag.

> 7.4p8 - missing word: ...predicate [in] the contact's matching set.

Fixed.

> 7.4p8&9 (and surrounding) - This is pretty hard to digest. Listing it

Its the standard issue of writing text which is effectively trying to 
convey what is ideally described using code. I don't think listing the 
steps in a bullet form as opposed to sentences will really help.

> 7.4p15 : s/prefentially/preferentially

Fixed.

> 
> 12p3: So, if I do a query register, would I expect to get back the
> feature sets contained in any registered contacts? If so, then
> worrying about protecting it in the original request does not seem 
> particularly useful.

Paul replied to this:
> Even query registers can (and probably should) be access controlled. So protecting still makes sense to me. 

I agree with him. I dont see why protecting it is useless. Sure, you 
need to protect the writes too, but just because someone else does the 
writes doesnt mean you shouldnt protect the reads.

> 16 ref 3: Is this really a normative reference? Also, no author

It was part of the registry listing for methods. Per Bob P.'s comments, 
I was able to remove the listing of existing methods and instead 
reference the IANA registry. Thus, the referece to the MESSAGE spec is gone.

Thanks for the comments!

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Ben Campbell <[email-masked]>
Date: 23 Apr 2003 09:22:54 -0500

On Wed, 2003-04-23 at 01:24, Jonathan Rosenberg wrote:

[...]

> absence of a VALUE for a feature tag.

Oops, sorry. The 6.1p4 reference was spurious. I was refering to the
register example at the end of 6.1. 

[...]

> steps in a bullet form as opposed to sentences will really help.

Is a C code fragment acceptable?