Subject: [RAI] draft-drage-rai-sip-header-process

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 7 Jul 2008 12:47:07 +0200

I have submitted the following draft:

http://www.ietf.org/internet-drafts/draft-drage-rai-sip-header-process-0
0.txt

I would welcome comments on the proposal.

A new version of I-D, draft-drage-rai-sip-header-process-00.txt has been
successfuly submitted by Keith Drage and posted to the IETF repository.

Filename:	 draft-drage-rai-sip-header-process
Revision:	 00
Title:		 Suggested process changes for handling new SIP headers
and SIP responses
Creation_date:	 2008-07-07
WG ID:		 Independent Submission
Number_of_pages: 12

Abstract:
RFC 3427 currently defines the process for defining and registering new
SIP header fields.  This document proposes that prefixs to header field
names should be discontinued, and that an additional category of
experimental header field should be created.  This document also relaxes
the requirement that response codes are defined by standards track RFCs,
also allowing them to be defined by experimental RFCs.

Regards

Keith
_______________________________________________
RAI mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rai

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jul 2008 12:42:25 -0400

Keith,

I think this is a welcome change. The only real reason I've ever been 
able to think of, around why P-headers need to be syntactically 
different, is if we had a requirement that they be removed at network 
boundaries without the proxy or b2bua understanding what the headers 
are. In other words, if you wanted, you could build a proxy which 
stripped all P-headers, even ones defined in the future. However, RFC 
3427 has never mandated that, and such behavior cannot be guaranteed, 
nor is it obvious its needed.

We also have precedent for a P-header which is now in widespread usage 
(P-Asserted-ID), and arguably should be made standards track. I don't 
want to open a debate on that - but merely state that, dropping the "P-" 
makes it much easier to make such a change for new headers that we 
decide to move from one category to another.

A related question is whether we plan on changing the definition of what 
conditions make something "private" vs. "full". These days, "P" headers 
typically are associated with trust domains - headers that only work in 
RFC3324 style federations (including single domain). However, we also 
have P-headers which are very specific to particular network 
architectures (for example, P-Profile-Key). I view these as two VERY 
different conditions.

Indeed, RFC3261 defines standards track header fields which are 
explicitly called out as really only being usable in trusted domains. 
Alert-Info and Call-Info are two examples. Indeed Section 20.9 says:

    Use of the Call-Info header field can pose a security risk.  If a
    callee fetches the URIs provided by a malicious caller, the callee
    may be at risk for displaying inappropriate or offensive content,
    dangerous or illegal content, and so on.  Therefore, it is
    RECOMMENDED that a UA only render the information in the Call-Info
    header field if it can verify the authenticity of the element that
    originated the header field and trusts that element.

This text makes it pretty clear that Alert-Info is much like 
P-Asserted-ID in terms of its scope of applicability. Yet its standards 
track.

I'll note further that, today, pretty much every SIP deployment is 
either within a single domain, or inter-domain, but amongst a closed set 
of peers. Whilst I would love to get to the point where we have open 
interconnection on the public Internet, much work remains (especially 
areas like SPIT/SPAM) to get there. So I expect it will still be some 
time before we arrive at that goal. It seems odd to me that, new SIP 
extensions which are defined to work within, what is today, 100% of SIP 
networks, should be considered "private" or "proprietary", seems odd.

So I'd propose that we also relax the definition of "private", so that 
extensions which are general purpose, but work only within trust 
domains, can be standards track. I do think such drafts should call that 
out in their security considerations, just as RFC 3261 calls out the 
warnings with Call-Info.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 12 Jul 2008 19:35:27 -0700

I would prefer to keep the discussion of this draft on the SIP list.

Thanks, Cullen