Subject: [Ietf-calsify] additional IANA considerations

From: lear at ofcourseimright.com (Eliot Lear)
Date: Mon Jun 18 00:26:26 2007

Hi,

Apologies for this being in XML, but it is intended for insertion.  I 
propose the following be inserted at the top of the IANA Considerations 
section.

<t>
    This section contains initial registrations for various protocol
    elements specified in this memo, as well as a table that explains
    what is required to add a new element.  Changing or removing an
    existing element requires a standards action.  In order to add
    a new element, where marked "RFC", that specification MUST
    make use of the following template:
</t>
<figure>
<artwork>
<![CDATA[

    Protocol Element Type:
    (e.g., Component, Property, Property Parameter, etc)
    Protocol element name:
    (MUST NOT begin with "X-")
    Short Description:
    (What it is)
    Long Description:
    In what contexts are the element valid?
    (Specify, for instance, where a property would be valid)
    Does this protocol element modify other existing elements?
    If so, describe:
    (For example, if a property parameter, how does it modify the
    property?)

]]></artwork>
</figure>
<t>
    Each answer MAY contain a normative reference.  No default values
    are allowed for properties or parameters.  Implementations that
    make use of a new protocol element MUST assume that they will
    interact with implementations that do not understand it.
</t>

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Tue Jun 19 17:23:47 2007

Hi Eliot,

Your proposal doesn't take into account the existing
Section 6 "Registration of Content Type Elements".

We should either:

1- Extend this section to contain all templates.
2- Move this section *in* the IANA Considerations section.
3- Move this section *after* the IANA Considerations section.

Also, I think we should consider having 4 templates:

- Registration of New Components
- Registration of New Properties
- Registration of New Parameters
- Registration of New Values

What do you think?

Cheers,
Bernard

---

From: lear at cisco.com (Eliot Lear)
Date: Tue Jun 19 22:49:54 2007

> 2- Move this section *in* the IANA Considerations section.

I think it was intended for (2), Bernard (insert in front of existing 
text).  I'm sorry if I didn't make that clear.  It wasn't a great "diff". 

> - Registration of New Values

I think there needs to be a substantial difference in the templates to 
justify four of them.  Do you think there is?

Eliot

---

From: alexey.melnikov at isode.com (Alexey Melnikov)
Date: Wed Jun 20 05:54:36 2007

> 3- Move this section *after* the IANA Considerations section.

IANA likes templates and all initial registrations to be subsections of 
a single top level section called "IANA considerations".
It is Ok to register things in other places, as long as the IANA 
considerations section contains pointers to relevant sections.

> - Registration of New Values

We can and should have 4 templates if they are sufficiently different.
In general I prefer separate templates, as it is easier to read (and 
this will also make IANA's job easier, as IANA people get occasionally 
confused by complex templates).

>> propose the following be inserted at the top of the IANA 
>> Considerations section.
>>
>>
>> <t>
>>    existing element requires a standards action.
>
I disagree about removing existing elements. An element must never be 
removed, it should be marked as "obsolete" instead.

>>   In order to add
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: lear at cisco.com (Eliot Lear)
Date: Wed Jun 20 05:58:05 2007

> removed, it should be marked as "obsolete" instead.

You are, of course, correct.  Replace word "removing" with "obsoleting".

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Wed Jun 20 12:03:48 2007

> text).  I'm sorry if I didn't make that clear.  It wasn't a great "diff".

I'm okay to move section 6 into the IANA Considerations section.

> justify four of them.  Do you think there is?

Here's what I have in mind.  A total of 5 templates.

   - Registration Template for New Components
   - Registration Template for New Properties
   - Registration Template for New Parameters
   - Registration Template for New Value Data Types
   - Registration Template for New Values

X.X.X  Registration Template for New Components

     A component is defined by completing the following template.

         To: [email-masked]

         Subject: Registration of new iCalendar component XXX

         Component Name:

         Purpose:

         Format Definition:

         Description:

         Example:

X.X.X  Registration Template for New Properties

     A property is defined by completing the following template.

         To: [email-masked]

         Subject: Registration of new iCalendar property XXX

         Property name:

         Purpose:

         Value type(s):

         Property parameter(s):

         Conformance:

         Description:

         Format definition:

         Example(s):

X.X.X  Registration Template for New Parameters

    A parameter is defined by completing the following template.

         To: [email-masked]

         Subject: Registration of new iCalendar parameter XXX

         Parameter Name:

         Purpose:

         Format Definition:

         Description:

         Example(s):

X.X.X  Registration Template for New Value Data Types

    A value data type is defined by completing the following template.

         To: [email-masked]

         Subject: Registration of new iCalendar value type XXX

         Value Name:

         Purpose:

         Format Definition:

         Description:

         Example(s):

X.X.X  Registration Template for New Values

    A value is defined by completing the following template.

         To: [email-masked]

         Subject: Registration of iCalendar value XXX

         Value:

         Conformance:

         Example(s):

Everybody should be familiar with the first four templates as
there are numerous examples of their use in RFC2445. As for the
last template, here's a fictitious example:

         To: [email-masked]

         Subject: Registration of iCalendar value TOP-SECRET

         Value: TOP-SECRET

         Conformance: This value can be used with the CLASS
            property.

         Example(s):

            CLASS:TOP-SECRET

Cheers,
Bernard

---

From: alexey.melnikov at isode.com (Alexey Melnikov)
Date: Thu Jun 21 06:57:10 2007

Hi Bernard,
Some questions/comments about the proposed templates below:

Bernard Desruisseaux wrote:

>> I think there needs to be a substantial difference in the templates 
>> to justify four of them.  Do you think there is?
>
>

I think all templates need to have a Usage field, which contains one of 
the following: limited, global, obsolete.

>         Subject: Registration of new iCalendar component XXX

How is Purpose different from Description?

What is Format Definition? Is it supposed to be ABNF or RFC reference?

>         Subject: Registration of new iCalendar property XXX

And this is an RFC reference? Why have you omitted this from the 
previous template?

---

From: lear at cisco.com (Eliot Lear)
Date: Thu Jun 21 07:03:41 2007

Alexey Melnikov wrote:
>
> I think all templates need to have a Usage field, which contains one 
> of the following: limited, global, obsolete.

Sounds like you're mixing semantics.  Do you mean "status"?  I think 
that's important too.  Also...
>>         Subject: Registration of new iCalendar component XXX

You don't need the "To: " line.

Eliot

---

From: alexey.melnikov at isode.com (Alexey Melnikov)
Date: Thu Jun 21 09:17:44 2007

Eliot Lear wrote:

> that's important too.

SASL registry uses "Usage", which is one of "limited", "common" or 
"obsolete". "obsolete" is something that shouldn't be used. "common" is 
something that is applicable to various use cases. "limited" is 
something known to be somewhat restricted/broken, but not sufficiently 
bad in order to be marked "obsolete".

So what do you mean by "status"?

>   Also...

This is more of a convention used by many IANA templates.