Subject: [Sip] draft-hilt-sip-ext-neg-00

From: Volker Hilt <[email-masked]>
Date: Thu, 20 Jan 2005 17:03:56 -0500

Folks,

we have submitted a draft, which defines a new Accept header field 
parameter that can be used to indicate support for MIME type extensions. 
In particular, this parameter can be used to indicate support for 
additional XML namespaces, which extend an XML-based media type.

http://www.ietf.org/internet-drafts/draft-hilt-sip-ext-neg-00.txt

Comments are very welcome.

-- Volker

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Fri, 28 Jan 2005 17:31:13 -0800

I don't know what to think of this. My gut reaction is that the Accept
mechanism is on the verge of breaking. If we do this, pretty soon every
single SIP messages is going to have 5k bytes of accept headers.

Perhaps we need to rethink about *when* certain things that could go in the
accept header are put in so not every messages has all of them.

Adam pointed out that the number of MIME types the average PC client can
accept is truly staggering and most clients just don't bother to provide
most of the but still accept them. This resulted in MSRP defining * to just
say, ok yah and give me whatever else you want.

If someone receives a geopriv XML extension inside some PIDF, they still
work because the XML allows them to skip what they don't understand. So I
guess I am asking what is a use case where we need this level of detail.

Cullen

PS - nice draft

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 29 Jan 2005 11:41:33 -0500

I think generally Accept-* makes sense if the receiver of that header 
has true choices in sending alternate content. This makes some, very 
limited, sense for content, where sometimes content is available in 
multiple formats, although this also seems to be rather rare in 
practice. In other cases, it doesn't really help much except to 
accelerate failure discovery and, maybe, avoid transmission of optional 
data that the receiver has to toss due to lack of understanding.

It is not clear that either case really applies to the labeling of XML 
schema.

---

From: Volker Hilt <[email-masked]>
Date: Sat, 29 Jan 2005 13:31:05 -0500

> data that the receiver has to toss due to lack of understanding.
I fully agree. The intension of this parameter is not that the sender of 
announces every single XML namespace it supports. The idea is that there 
are cases where it is useful for the receiver of an Accept header 
receiver to know which extensions the sender supports because it can 
provide content in different formats or wants to avoid costs for 
gathering and/or transmitting information that is tossed away.

An example where this is useful is PIDF-LO where the sender of an Accept 
header can announce the location object formats it supports (e.g. 
civilLoc). Another example are session policies, where the sender can 
announce supported policy extensions. E.g. if a firewall traversal 
extension is supported, the policy server can open pinholes and return 
the external addresses (which it shouldn't do if the client uses a 
different firewall traversal method). A third example is a wireless 
client that wants to use a minimal schema to minimize the size of a 
received document.

I agree with Cullens point that the use of this parameter needs to be 
limited to these (probably rare) cases where it is useful.

Thanks,

Volker

-- 
Volker Hilt                      Bell Labs / Lucent Technologies
phone: +1 732 332 6432           101 Crawfords Corner Rd
email: [email-masked]     Holmdel, NJ 07733