RFC 4244 (History-Info) also uses this mechanism to capture the Reason and Privacy associated with the URIs that are included as part of the History-Info header. My understanding is that it's really just a nifty way to compactly reuse existing headers (i.e., it makes the History-Info much more compact as I didn't need to define additional parameters for the header, but could rather reuse the existing ones, whose existing semantics perfectly applicable). I do think that the use of the headers that might be escaped using this mechanism should be explained, particularly in cases where you might be extending the use of existing headers as I did for the Privacy header.
Mary. -----Original Message----- From: Peili Xu [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 05, 2007 10:41 AM To: DRAGE, Keith (Keith) Cc: [email protected] Subject: Re: AW: AW: [Sip] Extension of conference procedures Yes, It's vague in RFC3261. I'm only aware of the usage in REFER now. It'll be good to clarify the semantics in the usage in url-list. 2007/9/5, DRAGE, Keith (Keith) <[EMAIL PROTECTED]>: > So this is a convenient way to bring us back to the other half of the issue which we do not seem to have discussed yet. When the syntax was defined that allowed ?headers: > > Headers: Header fields to be included in a request constructed > from the URI. > > Headers fields in the SIP request can be specified with the "?" > mechanism within a URI. The header names and values are > encoded in ampersand separated hname = hvalue pairs. The > special hname "body" indicates that the associated hvalue is > the message-body of the SIP request. > > What usage did the SIP WG envisage for this, and thus what semantics did they define for that usage. > > Is it appropriate to assign new semantics to such usage? > > Regards > > Keith > Note: I snipped the rest of this thread as it was getting really LONG. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
