Subject: [Sip] Moving along with the INFO discussion

From: Dean Willis <[email-masked]>
Date: Tue, 15 Jul 2008 13:19:52 -0500

We had a large, long, and lengthy thread of discussion that I will try
to summarize.

So far, almost everybody who has voiced an opinions says we need to fix,
rather than deprecate, INFO.

Opinions on fixing it vary.

Most people seem to think we need a registry of INFO usages that will,
at the very least, give us a table of the existing usages and the RFCs
or other specs that define them.

The sticky point of discussion is a negotiation and discovery mechanism.
We've had on-list proposals for a strong mechanism based on the mode
used in RFC 3265.

Some folks think we need to do this, and others thing there's no reason
to bother since it is not likely to get implemented because just
inventing a non-standard INFO use is easier.

Is there a middle ground?

What if we were to:

1) Establish an INFO registry and register our existing usages, policy
either "first come, first served" or "Specification required".

2) Define an Info-type header field and register (in the regoistry of
#1) a value for each known Info usage. Fully-compliant implementations
would send an Info-type header field with the appropriate value in every
INFO message.

3) Require registration of an Info-type for each future usage into the
registry of #1 above.

4) Define an "Info-type not supported" error response message. This
handles the use case of a UAS that receives an INFO with an Info-type it
does not understand.

5) For Info-types for which discovery is required, use a standards-track
RFC to define a SIP extension and option tag, and use the usual
OPTIONS/Require negotiation mechanism for discovery. We might consider
revising each INFO-using RFC to define an appropriate option tag.

This lets people easily register INFO usages and a corresponding
Info-type tag. It lets nodes that don't understand an Info-type usage
reject the message (at the expense of whacking the dialog, which
arguably was already in need of whacking). And it provides a standard
(although heavy) mechanism for discovery and negotiation when those are
required.

I think the above addresses the major concerns, is reasonably
implementable, is reasonably operable, and requires the smallest
possible effort to document. It's also pretty much backward compatible.

--
Dean
_______________________________________________
Sip mailing list  https://www.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: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Tue, 15 Jul 2008 15:03:59 -0400

My guess is that we would focus on "Standard-Track" INFO (e.g. # 5).

Of course, all others such vendor-specific INFO implementations can be added as a part of the above. For example, options can be built-in in the standard-track INFO to have those capabilities (e.g. #s 1, 2, 3, & 4) if one does not want to use the standardized one.

BR/Radhika

----- Original Message -----
From: Dean Willis 
Date: Tuesday, July 15, 2008 14:33
Subject: [Sip] Moving along with the INFO discussion
To: SIP IETF 

> The sticky point of discussion is a negotiation and discovery 
> mechanism.We've had on-list proposals for a strong mechanism based 
> on the mode
> used in RFC 3265.
> 
> Some folks think we need to do this, and others thing there's no 
> reasonto bother since it is not likely to get implemented because just
> would send an Info-type header field with the appropriate value in 
> everyINFO message.
> 
> 5) For Info-types for which discovery is required, use a standards-
> trackRFC to define a SIP extension and option tag, and use the usual

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jul 2008 15:09:19 -0400

> either "first come, first served" or "Specification required".

Its probably a little different from either of these existing policies.
Thats because it should only be applicable to *preexisting* usages.
We don't want new, yet to be deployed, usages registered in this way.
(We will probably have to use the honor system for determining which 
usages qualify.)

> would send an Info-type header field with the appropriate value in every

I think either this is a different registry, or else it is the same 
registry but a different class of entry.

I'm inclined to think it is a different registry because it is a 
different namespace. The namespace for (1) is mime-types, while for (2) 
it is a unique namespace of Info-types.

> revising each INFO-using RFC to define an appropriate option tag.

Revising the old usages is IMO counterproductive. They are what they are.

> arguably was already in need of whacking).

Its not even that bad. It only whacks the dialog if you put Requires in 
the dialog-establishing request. If you simply put it in the INFO 
itself, then the dialog doesn't get whacked.

> And it provides a standard

Works for me. Its pretty much what I had in mind.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jul 2008 15:12:09 -0400

IMO the registry of existing usages is at least, if not more, important 
than standardizing future usages. It gets all the proprietary usages out 
in the light of day. That will provide a way to understand what sort of 
mess we have.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 15 Jul 2008 14:22:38 -0500

On Jul 15, 2008, at 2:09 PM, Paul Kyzivat wrote:

>> mechanism.
>> reason

I'm proposing that new, yet-to-be-deployed INFO usages would be in the  
same registry. Only if they need a SIP Option Tag for negotiation  
would they need a standards-track RFC.

I do NOT want the SIP working group to live forever as the "INFO  
police". It just really doesn't matter that much what people put in an  
INFO as long as they don't hurt each other with conflicting usages.

>> every
Nope.

> different namespace. The namespace for (1) is mime-types, while for  
> (2) it is a unique namespace of Info-types.

That's not what I'm suggesting; it's NOT mime-types; it's Info-types  
in all cases. I'm saying we retroactively invent an Info-type for each  
documented existing usage. As people rev their old-use code, they  
would add the Info-type to their Info messages.

It might be OKAY to have a mime-type as an additional column in the  
registry, although that potentially leads us down an area of mime-type  
exclusion.

Do we also need a set of content-dispositions for each Info-type?

>> track

ok.

> Its not even that bad. It only whacks the dialog if you put Requires  
> in the dialog-establishing request. If you simply put it in the INFO  

Let's say that you send a 4XX error response to an in-dialog INFO  
(because you don't understand the Info-type of the dialog). What does  
that do to the dialog?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 15 Jul 2008 14:42:41 -0500

On Jul 15, 2008, at 2:12 PM, Paul Kyzivat wrote:

> IMO the registry of existing usages is at least, if not more,  
> important than standardizing future usages. It gets all the  
> proprietary usages out in the light of day. That will provide a way  
> to understand what sort of mess we have.

Possible registry structure:

Usage-Name  Info-type MIME-Type              Content-Disposition   
Option-Tag Specification
----------  --------- ---------------------  -------------------   
---------  -------------
ISUP        ISUP      application/ISUP       N/A                  N/ 
A        RFC 3398
QSIG        QSIG      application/QSIG       N/A                  N/ 
A        RFC 4497
DTMF        DTMF      application/dtmf       N/A                  N/ 
A        N/A
DTMF Relay  DTMFrel   application/dtmf-relay N/A                  N/ 
A        draft-kaplan-sipping-dtmf-package-01
Snapshot    snapshot  image/jpeg             render                
snapshot   draft-ietf-sip-snapshot-00 (std track)

Here's a question: The ISUP docs use an outer multipart MIME type,  
with the application/whatever inside. What does it mean when you have  
an INFO containing multiple parts of mismatched types?

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Tue, 15 Jul 2008 14:48:06 -0500

> (because you don't understand the Info-type of the dialog). What does 

Depends on the 4XX.

404, 410, 416, 482, 483, and 485 destroy the dialog. 405, 480, 481, 489 
destroy the INVITE usage, which will usually destroy the dialog. Pretty 
much any other 4XX only impact the transaction.

See RFC 5057 for the details.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 15 Jul 2008 14:51:09 -0500

On 7/15/08 2:48 PM, Adam Roach wrote:
>
> 405, 480, 481, 489 destroy the INVITE usage...

Gack. That's the general case. For INFO in particular, a 405 response 
won't kill the usage. But you get the basic idea.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 15 Jul 2008 14:56:18 -0500

> an INFO containing multiple parts of mismatched types?

INFO tunneling of mid-call ISUP information won't be multipart -- it'll 
just be application/ISUP.

/a

---

From: Dean Willis <[email-masked]>
Date: Tue, 15 Jul 2008 16:42:14 -0500

On Jul 15, 2008, at 2:48 PM, Adam Roach wrote:

>> (because you don't understand the Info-type of the dialog). What  
>> does that do to the dialog?
>
> Depends on the 4XX.
>
> 404, 410, 416, 482, 483, and 485 destroy the dialog. 405, 480, 481,  
> 489 destroy the INVITE usage, which will usually destroy the dialog.  
> Pretty much any other 4XX only impact the transaction.
>

So let's say you return the new 4xx response to an old-fashioned  
sender who doesn't understand the 4xx response. It gets treated as a  
400. This doesn't destroy the dialog or the dialog usage, but kills  
the INFO transaction.

I have no idea what that does to the sender's state, and I'm pretty  
sure the sender doesn't either. Can we live with that? I'd think it  
would be better if it destroyed the dialog usage, but AFAIK we have no  
way of specifying such behavior in a backward-compatible manner  
(unless we reuse 405, 480, 481, or 489). What do we know about real- 
world implementations treatment of these responses? Is everything RFC  
5057 compliant?

---

From: Adam Roach <[email-masked]>
Date: Tue, 15 Jul 2008 16:52:39 -0500

On 7/15/08 4:42 PM, Dean Willis wrote:
> (unless we reuse 405, 480, 481, or 489). 

I should have chased down all the footnotes before I posted; as I 
mentioned in an earlier mail, 405 to INFO doesn't tear down the usage. 
In addition to that, 489 to an INFO isn't defined, and 5057 calls it 
reasonable to treat it as a 400. 480 and 481 are clearly the wrong 
answer. So there's not a reasonable way to leverage 5057 to make the 
usage fail when an INFO type isn't recognized.

However: I don't think we *want* the usage to fall down when an INFO 
fails. That was a key decision we took during the development of 5057.

/a

---

From: Dean Willis <[email-masked]>
Date: Tue, 15 Jul 2008 17:19:21 -0500

On Jul 15, 2008, at 4:52 PM, Adam Roach wrote:

>>> 404, 410, 416, 482, 483, and 485 destroy the dialog. 405, 480,  
>>> 481, 489 destroy the INVITE usage, which will usually destroy the  
>>> dialog. Pretty much any other 4XX only impact the transaction.
>>>
>> sender who doesn't understand the 4xx response. It gets treated as  
>> a 400. This doesn't destroy the dialog or the dialog usage, but  
>> kills the INFO transaction.
>>
>> would be better if it destroyed the dialog usage, but AFAIK we have  
>> no way of specifying such behavior in a backward-compatible manner  
> mentioned in an earlier mail, 405 to INFO doesn't tear down the  
> usage. In addition to that, 489 to an INFO isn't defined, and 5057  
> calls it reasonable to treat it as a 400. 480 and 481 are clearly  
> the wrong answer. So there's not a reasonable way to leverage 5057  
> to make the usage fail when an INFO type isn't recognized.
>

That's why I asked "Can we live with that?"

Let's step through the use cases.

Alice is an INFO sender for DTMF. She's talking to a new voice mail  
system and starts sending it info-dtmf-relay. The VM doesn't  
understand, so it 4xxes the INFO. Is Alice better served by having the  
call drop or her DTMF attempt ignored? I suspect here that "ignore",  
with its potential of a UI indicator to Alice saying "My attempt to  
send info-dtmf-relay failed", is probably better than the call dropping.

How about the ISUP and QSIG use cases? I'm guessing they would fail  
typically not with the new 4xx, but with the 415 Unsupported as  
documented in RFC 3372.

So it looks like you've convinced me; it's better for the INFO failure  
to NOT drop the dialog or dialog usage.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jul 2008 20:27:04 -0400

Dean,

It does no good to retroactively invent new info usages for the existing 
usages of INFO, because the implementations don't know about them. They 
figure out that it is *their* usage from context, which in practice ends 
up being content-type. (I suppose its *possible* that somebody overloads 
a c-t and discriminates on some other basis, but I strongly doubt it.)

But the new ones are going to discriminate on info-type, not 
content-type. At least I think so.

The only way you can force them all into the same namespace is by making 
all the new ones discriminate based on c-t.

Having two namespaces/registries does not require the sip wg to stay 
around as police. All we need to do is define the admission rules. A 
simple rule would be:
- the usage had to exist before date D1
- it must be added to the registry before date D2
- FCFS per C-T
Then on D2 that registry is permanently closed. That means that anybody 
with an existing usage needs to hurry to get it registered.

Or, we can forget about D2, and leave the registry open forever on a 
FCFS basis per C-T, with a proviso that only usages that were in 
existence prior to D1 are eligible. (But with no enforcement mechanism 
for that.)

Now that I think about it, maybe it can't even be FCFS per C-T. If it 
turns out that more than one usage uses the same C-T, then they can't 
interoperate, but presumably they still exist. I guess we would need to 
register them and note the conflict, as a warning to users. Hopefully 
this won't happen in practice.

	Paul

Dean Willis wrote:
> same registry. Only if they need a SIP Option Tag for negotiation would 
> they need a standards-track RFC.
> 
> That's not what I'm suggesting; it's NOT mime-types; it's Info-types in 
> all cases. I'm saying we retroactively invent an Info-type for each 
> documented existing usage. As people rev their old-use code, they would 
> add the Info-type to their Info messages.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Jul 2008 23:36:08 -0400

I agree with Paul; these need to be different registries.

I also agree that inventing a new info framework will NOT make us the 
INFO police; quite the opposite. I think we make it easier to do vendor 
proprietary stuff (within a vendor namespace), and we can define the 
extension procedure such that the bar is lowered for things that folks 
want cross-vendor interop but don't want to go through the whole ietf 
process.

Frankly, I think the framework defined in Hadriels' draft is pretty 
barebones minimum - its basically a couple of headers which define what 
you support.

I do NOT want to use the existing option tags mechanism for this - or 
Require/Supported - it then requires standards track for these and we 
don't want that.

-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
_______________________________________________
Sip mailing list  https://www.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: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 16 Jul 2008 14:41:09 +0200

Q.1912.5 and RFC 3204 specify what you are trying to do at the body
level rather than at the INFO transaction level.

Thus it sets the Content-Disposition header parameter handling to
"required". (Note that Q.1912.5 mandates this setting whereas RFC3398
does not constrain it, essentially leaving it to the implementor). The
response if this is set, and the receiving entity is not able to
understand it, is to send a 415. While this is defined in RFC 3204, it
does get a normative reference from RFC 3261 so I assume this parameter
and its handling is mandatory to implement for all RFC 3261
implementations, rather than specific to ISUP/QSIG.

415 destroys the transaction only.

Q.1912.5 doesn't seem to mandate anything useful with the 415 response
in any case.

In any case, if you are using INFO to encapsulate an ISUP message, I
would assume you had already encapsulated such a body in an INVITE
message earlier in the sequence, and therefore you would have performed
the Content-Disposition / 415 sequence on an INVITE transaction already.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dean Willis
> Sent: Tuesday, July 15, 2008 11:19 PM
> To: Adam Roach
> Cc: SIP IETF; Paul Kyzivat
> Subject: Re: [Sip] Moving along with the INFO discussion
> 
> 
> Alice is an INFO sender for DTMF. She's talking to a new 
> voice mail system and starts sending it info-dtmf-relay. The 
> VM doesn't understand, so it 4xxes the INFO. Is Alice better 
> served by having the call drop or her DTMF attempt ignored? I 
> suspect here that "ignore", with its potential of a UI 
> indicator to Alice saying "My attempt to send info-dtmf-relay 
> failed", is probably better than the call dropping.
> 
> How about the ISUP and QSIG use cases? I'm guessing they 
> would fail typically not with the new 4xx, but with the 415 
> Unsupported as documented in RFC 3372.
> 
> So it looks like you've convinced me; it's better for the 
> INFO failure to NOT drop the dialog or dialog usage.
> 
> --
> Dean
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Eric Burger <[email-masked]>
Date: Wed, 23 Jul 2008 12:45:14 -0400

In this case, I would offer we have the same, awful user experience.   
Alice connects to the VM system, and the call is immediately dropped  
(dialog dies).  Alice calls her service provider and says, "Voice Mail  
is broken."  Or, Alice connects to the VM system, and the VM system is  
totally unresponsive (dialog does not die).  Alice calls her phone  
manufacturer and says, "your phone doesn't work" or calls her service  
provider and says, "my phone doesn't work."

Now assume your very highly paid customer service rep at the service  
provider trying to debug the dialog does not die scenario...

On Jul 15, 2008, at 6:19 PM, Dean Willis wrote:
> [snip]
> understand, so it 4xxes the INFO. Is Alice better served by having  
> the call drop or her DTMF attempt ignored? I suspect here that  
> "ignore", with its potential of a UI indicator to Alice saying "My  
> attempt to send info-dtmf-relay failed", is probably better than the  
> call dropping.
>
> So it looks like you've convinced me; it's better for the INFO  
> failure to NOT drop the dialog or dialog usage.
[snip]

---

From: Eric Burger <[email-masked]>
Date: Wed, 23 Jul 2008 12:48:24 -0400

Must be different registries for all the reasons JDR & Paul mention.

I am torn on the Proprietary Registry, however.  We *think* we know  
all the bizarre ways people use INFO in the world, but I am constantly  
surprised by some of the "unique" things that get discussed on the SIP  
Forum Discussion list.  On the one hand, we would want to have an open  
call for proprietary implementations so we can register and analyze  
them.  On the other hand, one could see how that could encourage new,  
yet obsolete, INFO usages.

Given that at least two of the extant INFO I-D's enumerate the classes  
of INFO usage in the wild, is there ANY value to a Proprietary INFO  
Registry?

On Jul 15, 2008, at 11:36 PM, Jonathan Rosenberg wrote:

> I also agree that inventing a new info framework will NOT make us  
> the INFO police; quite the opposite. I think we make it easier to do  
> vendor proprietary stuff (within a vendor namespace), and we can  
> define the extension procedure such that the bar is lowered for  
> things that folks want cross-vendor interop but don't want to go  
> through the whole ietf process.
>
> barebones minimum - its basically a couple of headers which define  
> what you support.
>
> I do NOT want to use the existing option tags mechanism for this -  
> or Require/Supported - it then requires standards track for these  
> and we don't want that.
>
> -Jonathan R.
>
>
> Paul Kyzivat wrote:
>> Dean,
>> It does no good to retroactively invent new info usages for the  
>> existing usages of INFO, because the implementations don't know  
>> about them. They figure out that it is *their* usage from context,  
>> which in practice ends up being content-type. (I suppose its  
>> *possible* that somebody overloads a c-t and discriminates on some  
>> other basis, but I strongly doubt it.)
>> The only way you can force them all into the same namespace is by  
>> making all the new ones discriminate based on c-t.
>> Having two namespaces/registries does not require the sip wg to  
>> stay around as police. All we need to do is define the admission  
>> rules. A simple rule would be:
>> Then on D2 that registry is permanently closed. That means that  
>> anybody with an existing usage needs to hurry to get it registered.
>> Or, we can forget about D2, and leave the registry open forever on  
>> a FCFS basis per C-T, with a proviso that only usages that were in  
>> existence prior to D1 are eligible. (But with no enforcement  
>> mechanism for that.)
>> Now that I think about it, maybe it can't even be FCFS per C-T. If  
>> it turns out that more than one usage uses the same C-T, then they  
>> can't interoperate, but presumably they still exist. I guess we  
>> would need to register them and note the conflict, as a warning to  
>> users. Hopefully this won't happen in practice.
>>    Paul
>> Dean Willis wrote:
>>>
>>>> (We will probably have to use the honor system for determining  
>>>> which usages qualify.)
>>>
>>> I'm proposing that new, yet-to-be-deployed INFO usages would be in  
>>> the same registry. Only if they need a SIP Option Tag for  
>>> negotiation would they need a standards-track RFC.
>>>
>>> police". It just really doesn't matter that much what people put  
>>> in an INFO as long as they don't hurt each other with conflicting  
>>> usages.
>>>
>>>>
>>>>
>>>> I think either this is a different registry, or else it is the  
>>>> same registry but a different class of entry.
>>>>
>>> Nope.
>>>
>>>> different namespace. The namespace for (1) is mime-types, while  
>>>> for (2) it is a unique namespace of Info-types.
>>>
>>> That's not what I'm suggesting; it's NOT mime-types; it's Info- 
>>> types in all cases. I'm saying we retroactively invent an Info- 
>>> type for each documented existing usage. As people rev their old- 
>>> use code, they would add the Info-type to their Info messages.
>>>
>>> It might be OKAY to have a mime-type as an additional column in  
>>> the registry, although that potentially leads us down an area of  
>>> mime-type exclusion.
>>>
>>>> Its not even that bad. It only whacks the dialog if you put  
>>>> Requires in the dialog-establishing request. If you simply put it  
>>>> in the INFO itself, then the dialog doesn't get whacked.
>>>

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Wed, 23 Jul 2008 20:10:06 -0400

I agree, it depends on the use cases and one rule does not apply in all
cases. Another use case is for an IVR system and in that case as well,
where if dtmf usage does not work, there is no point in continuing with
the dialog.

Sanjay 

>Behalf Of Eric Burger
>Sent: Wednesday, July 23, 2008 12:45 PM
>To: SIP IETF
>Alice connects to the VM system, and the call is immediately 
>dropped (dialog dies).  Alice calls her service provider and 
>says, "Voice Mail is broken."  Or, Alice connects to the VM 
>system, and the VM system is totally unresponsive (dialog does 
>not die).  Alice calls her phone manufacturer and says, "your 
>phone doesn't work" or calls her service provider and says, 
>"my phone doesn't work."
>
>Now assume your very highly paid customer service rep at the 
>service provider trying to debug the dialog does not die scenario...
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Jul 2008 13:17:05 -0400

I would think it would be advisable for the UAC in this case to provide 
some sort of feedback to the user that the dtmf isn't working.
E.g. instead of playing the dtmf tone to its user, it could play 
nothing, or some error tone. Would probably hear the normal tone for the 
first button pressed, but after that, when the UAC has received an error 
for the INFO, the other behavior would kick in.

This of course doesn't *solve* the problem. But then nothing will short 
of the UAS supporting the dtfm.

If the UAS doesn't support DTMF, there will be a problem even if the 
dtmf is sent in the media stream. Probably if telephone-events can't be 
negotiated the tones will simply be sent in the audio stream, and there 
will be no feedback if they aren't understood. So almost anything done 
here will be an improvement.

	Paul

---

From: Eric Burger <[email-masked]>
Date: Mon, 28 Jul 2008 10:50:14 +0100

Good news: #5 exactly the mechanism RFC 5022 uses.  Brilliant (or  
toasted) minds think alike.

Bad news: it does not solve the interoperability problem in its  
entirety. It means that the MSCML endpoints are sure they understand  
each other. However, if some one *also* does Cisco DTMF INFO, there is  
no way of signaling that, or that a particular INFO message is MSCML  
or DTMF, other than for the fact the Content-Type *hopefully* will be  
different.

Note Content-Type is not enough to solve the problem in the abstract,  
although it works for the known usages.  That means I would NOT  
advocate relying on Content-Type to disambiguate INFO messages.

---

From: Eric Burger <[email-masked]>
Date: Mon, 28 Jul 2008 11:16:34 +0100

If we do a registry for "Bad INFO" usage, I would offer we call it a  
catalog.  My strong preference is NOT to have an IANA registry, as  
that looks like a protocol.  My personal opinion is such a catalog  
(registry) is actually a BAD thing.  If you think Individual  
Informational RFC's get misinterpreted, just wait until we build an  
INFO Registry.