[sipcore] #3: Gaps in H-I headers should NOT be treated as "malicious"

["sipcore issue tracker" <[e-mail]>]

#3: Gaps in H-I headers should NOT be treated as "malicious"
------------------------------------+---------------------------------------
 Reporter:  hkaplan@…               |       Owner:            
     Type:  defect                  |      Status:  new       
 Priority:  major                   |   Milestone:  milestone1
Component:  rfc4244bis              |     Version:  2.0       
 Severity:  In WG Last Call         |    Keywords:            
------------------------------------+---------------------------------------
 Section 4.1 and 4.2.1 both say "The entries SHOULD be evaluated to
 determine gaps in indices, which could indicate that an entry has been
 maliciously removed."

 That's a bad SHOULD.  First, because it doesn't actually tell you what to
 do if they're missing.  Second, because if missing indeces actually cause
 a request failure, that's a good way of guaranteeing people won't use
 hist-info or will delete ALL the entries just to make calls work.  Third,
 because it's highly unlikely to actually be due to "malicious" reasons -
 if someone wants to "maliciously" remove them, they'll delete them all, or
 change them all, etc.  It's more likely they were removed for
 security/privacy reasons.

 Please remove this sentence from both sections.
 In fact, maybe a sentence should be added to remind people missing indeces
 are possible and OK. (i.e., MUST NOT cause a request faiure)

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/sipcore/trac/ticket/3>
sipcore <http://tools.ietf.org/sipcore/>