Subject: [Sip] GRUU and grid

From: [email-masked]
Date: Thu, 21 Sep 2006 13:18:19 -0400

I was distracted during part of the last phone call, so I think I
heard the following idea discussed and largely agreed on.  But maybe
not.  Can people fill me in, or explain the ramifications of this
idea?

In previous drafts, a UA could convert a GRUU into a series of GRUU
URIs that would all route to the UA by adding a URI-parameter
"grid=(value)":

	sip:[email-masked] --> sip:[email-masked];grid=abcde

Then the proxy responsible for the GRUU would carry the grid parameter
into the contact URI that was the final request-URI:

	sip:[email-masked];grid=abcde routes to
		sip:10.1.1.1;grid=abcde

EKR among others noted that this was rather clunky and non-orthogonal
to the rest of the SIP addressing structure.

But the same effect could be obtained by using a header (in RFC 3261
terminology):

	sip:[email-masked] --> sip:[email-masked]?grid=abcde

At whatever stage of processing (UAC or proxy) this URI is inserted as
a request-URI, the header will be removed from the URI and turned into
a header field (RFC 3261 terminology):

	INVITE sip:[email-masked]
	grid: abcde

The header field will be copied by all proxies and eventually reach
the UAS.

The UAS can thus test for the "grid" header field in the same way that
it could previously test for the "grid" URI-parameter in the previous
proposals.

This new scheme has a number of advantages:

- It requires no new mechanisms, as this processing of headers into
  header fields is specified by RFC 3261.

- It is as easy for the UA to use as the URI-parameter.

- It requires reserving one header field name vs. reserving one
  URI-parameter name.

- UAs (or different layers of processing) could use the same mechanism
  for multiple additional values (as long as they use different header
  field names).

Dale

_______________________________________________
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: Thu, 21 Sep 2006 14:43:40 -0400

Dale,

If header parameters had been made mandatory in 3261 this would probably 
work well. But inclusion of header parameters into requests is 
discretionary in 3261, and there are warnings of how it can be 
dangerous, so I don't believe it can be relied upon.

If it were only the proxy handing out the gruu that had to be relied 
upon it wouldn't be a problem, because we could make it a mandatory part 
of gruu support. But that isn't the case. Done as you suggest it is the 
server that is putting the request into the R-URI of a request that must 
do it. So I think it would be a quite unreliable mechanism.

	Paul

---

From: [email-masked]
Date: Sun, 24 Sep 2006 22:46:50 -0400

From: Paul Kyzivat <[email-masked]>

   If header parameters had been made mandatory in 3261 this would
   probably work well. But inclusion of header parameters into
   requests is discretionary in 3261, and there are warnings of how it
   can be dangerous, so I don't believe it can be relied upon.

My reading is that including a header parameters is mandatory unless
the UA has a positive reason not to include it.  Maybe that means that
some UAs don't bother to process any header parameter, but that seems
to me to be a violation.

Dale

---

From: Tina TSOU From [email-masked] Sun Sep 24 22:49:24 2006
Date: Mon, 25 Sep 2006 10:39:19 +0800

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Sep 2006 11:55:31 -0400

> some UAs don't bother to process any header parameter, but that seems

What did you use to form your interpretation? The following is from 19.1.5:

    An implementation SHOULD treat the presence of any headers or body
    parts in the URI as a desire to include them in the message, and
    choose to honor the request on a per-component basis.

    An implementation SHOULD NOT honor these obviously dangerous header
    fields: From, Call-ID, CSeq, Via, and Record-Route.

    An implementation SHOULD NOT honor any requested Route header field
    values in order to not be used as an unwitting agent in malicious
    attacks.

    An implementation SHOULD NOT honor requests to include header fields
    that may cause it to falsely advertise its location or capabilities.
    These include: Accept, Accept-Encoding, Accept-Language, Allow,
    Contact (in its dialog usage), Organization, Supported, and User-
    Agent.

    An implementation SHOULD verify the accuracy of any requested
    descriptive header fields, including: Content-Disposition, Content-
    Encoding, Content-Language, Content-Length, Content-Type, Date,
    Mime-Version, and Timestamp.

This seems to give the UA complete freedom to ignore the desire to 
include headers as it sees fit. Given the requirement not to include any 
obviously dangerous header fields. I expect that a UA will would be 
imprudent if it included any header field it doesn't understand.

	Paul

---

From: [email-masked]
Date: Mon, 25 Sep 2006 19:17:22 -0400

I take "SHOULD" as meaning "Do it unless you've got a good reason not
to."

But has anyone taken a survey on what real UAs do?  It seems that's
the important question.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Sep 2006 09:33:28 -0400

> I take "SHOULD" as meaning "Do it unless you've got a good reason not

I agree with you about the meaning of SHOULD. But the quote is worded in 
an unusual way. It doesn't say the implementation should include them in 
the request. It says the implementation should treat the presence of the 
header as a desire (on the part of creator of the URI I presume) to have 
them included in the message, and that the implementation should "choose 
to honor the request on a per-component basis".

The last is a little bit vague. I take it to mean that the 
implementation should *choose* (that is follow the policy of the 
implementation) to honor *each* header in the URI on a header by header 
basis based on local policy for that header.

So I think all the SHOULD is saying is that the implementation should 
not ignore the headers out of hand, but instead should apply a local 
policy to each one. But it could still be the case that the local policy 
for all headers is to leave them out.

> But has anyone taken a survey on what real UAs do?  It seems that's

I agree, and I don't know. Maybe Robert has some data from SIPIT.

	Paul

---

From: [email-masked]
Date: Tue, 26 Sep 2006 22:23:24 -0400

Yeah, I have to admit you have a point there.

There's a SIPit coming up in a month...

Dale