Subject: [sipcore] rfc4244bis: backwards compatibility

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 15 Jul 2009 18:47:59 -0400

And now for a horse of a different color...

The section on backwards compatibility states:
   Proxies conforming to this specification tag the hi-entry parameters
   with an hi-target parameter.  The hi-target and hi-aor parameters did
   not exist in [RFC4244]; therefore, [RFC4244] implementations do not
   tag the hi-entry parameters.  This tagging allows for distinguishing
   entries that were added by an [RFC4244] entity, versus one that was
   added by an entity conforming to this specification.

So what is a UAS to do with entries that were created by an RFC4244 device, and not tagged as "aor" nor "mp"?

Does it:
1) Treat them as implicitly tagged with both.
2) Treat them as implicitly tagged with neither.
3) Treat them as implicitly tagged with one or the other.

By "treat them" I mean for the purpose of narrowing down the list of entries (i.e., removing fluff), as well as for any application-specific usage of such entries.

Furthermore, since a Proxy modifies a previous H-I entry by adding an "aor" tag if it treated its URI as a AoR - what does a Proxy which receives a previous H-I entry that does not have any tag do - can/should it still add an "aor" tag to that entry if it handles it as an AoR?  (note that this means a UAS will receive a H-I entry which does not have a "mp" or any fluff tag but does have an "aor" tag)

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Jul 2009 18:07:15 -0500

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Wednesday, July 15, 2009 15:48
> To: SIPCORE
> Cc: [email-masked]
> Subject: rfc4244bis: backwards compatibility
> 
> So what is a UAS to do with entries that were created by an 
> RFC4244 device, and not tagged as "aor" nor "mp"?
> 
> Does it:
> By "treat them" I mean for the purpose of narrowing down the 
> list of entries (i.e., removing fluff), as well as for any 
> application-specific usage of such entries.

It reverts back to old RFC 4244 behavior, i.e.,

If (manufacturer-or-service-provider == X1) then Y1()
else if (manufacturer-or-service-provider == X2) then Y2()
else if (manufacturer-or-service-provider== X3) then Y3()
else Y4()

(Half joking).

Seriously, it did what it did before. It's not going to work any better with
non-conforming proxies.

When it sees the tag, it reduces the ambiguity. Otherwise, it's basically
doing what it did before.

Now, what if it didn't support HI before?

I would think that you would basically just implement the new 4244
and ignore the non-tagged entries, i.e., treat them a fluff.

> Furthermore, since a Proxy modifies a previous H-I entry by 
> adding an "aor" tag if it treated its URI as a AoR - what 
> does a Proxy which receives a previous H-I entry that does 
> not have any tag do - can/should it still add an "aor" tag to 
> that entry if it handles it as an AoR?  (note that this means 
> a UAS will receive a H-I entry which does not have a "mp" or 
> any fluff tag but does have an "aor" tag)

Yes, you could have that. I believe that is covered in the spec.
There are procedures in the steps (both for Proxies and Redirect
server) that explains that they populate the entry on behalf of the
previous hop.

This applies obviously if "the previous hop" was not RFC 4424 compliant,
or if the previous hop was a UAC (which wouldn't normally include 
HI). In this case, proxy/redirect-server includes the entry on it's'
behalf. This is actually unchanged from 4244 (althoug it's much more
explicit in this draft).

The other case is when the entry is there, but it's not tagged. Then
yes, the proxy would tag it too.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 16 Jul 2009 09:56:09 +0200

I still do not like this implicit versioning requirement on the tags. Either
we do versioning or we don't, but do not fold it in to the meaning of the
other tags.
Get the feeling that the only reason that the fluff tags (cc, rc, rt) exist
is because of this implicit versioning requirement.

I vote for no versioning. Do n't thisnk that it is required.

/Hans Erik van Elburg

On Thu, Jul 16, 2009 at 12:47 AM, Hadriel Kaplan <[email-masked]>wrote:

> This tagging allows for distinguishing

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 16 Jul 2009 09:11:23 -0500

I think versioning is somewhat of a misnomer for what we're doing here.
We are relying entirely on normal SIP extensibility mechanisms whereby
an entity that needs a certain parameter needs to be able to handle the
fact that another entity might not support the header or specific
parameters.  And, from the 4244 perspective, this requirement is already
there since History-Info is optional. An application that relies on the
new tags needs to have default behavior when the tags are not there.
The reason we want to tag all the entries added by entities that do
understand what these tags mean, is so that an application has a level
of confidence that the specific hi-entry is NOT one that they care about
- that might just help them be able to make use of an entry that isn't
tagged, for example.  From the protocol perspective, the objective is to
provide as complete of information as possible (a core requirement for
History-Info) - it's up to the specific application to figure out how
relevant each bit of information is.
 
Mary. 

________________________________

From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Thursday, July 16, 2009 2:56 AM
To: Hadriel Kaplan
Cc: SIPCORE; [email-masked]
Subject: Re: rfc4244bis: backwards compatibility

I still do not like this implicit versioning requirement on the tags.
Either we do versioning or we don't, but do not fold it in to the
meaning of the other tags. 

Get the feeling that the only reason that the fluff tags (cc, rc, rt)
exist is because of this implicit versioning requirement.

/Hans Erik van Elburg

On Thu, Jul 16, 2009 at 12:47 AM, Hadriel Kaplan
<[email-masked]> wrote:

	This tagging allows for distinguishing
	  entries that were added by an [RFC4244] entity, versus one
that was
	  added by an entity conforming to this specification.