Subject: [Speechsc] IANA considerations for group feedback

From: Dan Burnett <[email-masked]>
Date: Fri, 21 Jan 2005 10:51:33 -0800 (PST)

Group,

In the course of reviewing the draft in order to write
the IANA Considerations sections, I've identified the
following value spaces for which one might consider
requesting IANA to maintain a registry.  For each one,
I've made a suggestion as to whether or not we should
create an IANA registration, and if so, what policy
(see [1] for explanations) should be used for
assignment.  The default policy in the document for
all remaining value spaces will be that there must be
a new version of MRCP for any changes to occur.

I would like to hear if there are any opinions on
these, particularly if they differ from my
suggestions.
I would also like particularly to hear feedback on 2
and 5, below, since my suggested assignment protocol
may be quite restrictive with respect to vendor
extensions.

1. Name space: resource types (sec. 4.2)
IANA registry?: no
Comment: This is a core part of the spec and requires
significant understanding and industry consensus. The
introduction of a new resource should require approval
of a working group and not just one expert.

2. Name space: extension methods (sec. 5.1)
IANA registry?: yes
Assignment protocol: IETF Review
Comment: It should be possible to extend the set of
methods without creating a whole new version of MRCP. 
Or should it?  If not, why do we permit it in the
spec?

3. Name space: request state (sec. 5.2)
IANA registry?: no
Comment: This is unlikely to change.  If there were a
need to change this it would probably require a
re-think of the entire protocol.

4. Name space: status codes (sec. 5.2)
IANA registry?: yes
Assignment protocol: Specification Required with
Expert Review
Comment:  This is the sort of thing that might need to
be adjusted based on further implementation experience
by the industry.  It should not require a re-write of
the spec, but any additions would need to be reviewed
for sanity and documented for portability.  By the
way, I would recommend that we include a small number
of codes specifically for experimental use (see [2]).

5. Name space: extension events (sec. 5.3)
IANA registry?: yes
Assignment protocol: IETF Review
Comment: It should be possible to extend the set of
events without creating a whole new version of MRCP. 
Or should it?  If not, why do we permit it in the
spec?

6. Name space: extension headers (sec. 6.1)
IANA registry?: yes
Assignment protocol: IETF Review
Comment: It should be possible to extend the set of
headers without creating a whole new version of MRCP. 
Or should it?  If not, why do we permit it in the
spec?

7. Name space: vendor-specific headers (sec. 6.1)
IANA registry?: no
Comment: Such parameters are already clearly
identified by the "Vendor-Specific-Parameters" prefix
and thus the  contents are well-known to be
vendor-specific.

8. Name space: parameter list (sec. 6.2/6.3)
IANA registry?: yes
Assignment protocol: IETF Review
Comment: This one I'm not sure about.  It's similar to
2 and 5, above, but the draft does not currently
provide a slot for such extensions (i.e. the list is
currently closed).  I think the permissability of
extensions here should match that for 2 and 5, whether
we permit extensions for all (without a new MRCP spec)
or whether we prohibit all extenions (and require a
new MRCP spec for changes).

9. Name space: completion cause (for each resource)
IANA registry?: no
Comment: Although I think there might be some use in
having a registry for each, it seems like overkill to
do it.  I could be persuaded otherwise, however.

-- Dan

[1]
http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434bis-01.txt
[2] ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt

__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: Sarvi Shanmugham <[email-masked]>
Date: Fri, 21 Jan 2005 12:30:45 -0800

comments line.

>of a working group and not just one expert.
I believe this was one the items to be registered with the IANA.  
Registering with the IANA by itself
does not make it any more easy or difficult to add new resource types. 
The idea behind the MRCP framework, its resource types and the way the 
protocol is modeled is that future RFCs can propose to add more 
resources definitions extensions to handle such resources.

New resources may be added into the framework in the future by defining 
a new RFC thats specifies the working of that resource as long as it 
does not change the framework or existing resources.  Only if the 
existing resources and their working are being changed or upgraded in 
the future would a new RFC to override this be needed.

So I believe this needs to be registered.

>Or should it?  If not, why do we permit it in the
Yes. New extenion methods can be poposed through additiona RFCs as long 
as they don't change the behaviour of the existing methods and headers. 
If existing functionality is being changed, I believe you would need a 
new version of MRCP RFC to supercede this one.

>re-think of the entire protocol.
agreed.

>of codes specifically for experimental use (see [2]).
agreed.

>Or should it?  If not, why do we permit it in the
Agreed. This the same as extending methods. I think methods and events 
should be in the same namespace to avoid conflicting choices for method 
names and event names.

>Or should it?  If not, why do we permit it in the
Agreed.

>and thus the  contents are well-known to be
The question then is how is the server or client to recognize which 
vendors resource it is and hence what parameters it supports?

>new MRCP spec for changes).
Yes this should also be extensible.

>do it.  I could be persuaded otherwise, however.
The meaning of Completion Cause resource specific. Hence I think future 
resources, if any, would define their own list of values.
So I agree with the above.

Additional IANA registered value.
One other value that needs to be registered is the vendor specific ID 
for the recognizer context block
Refer "Recognizer Context Block" in section 9.5 and the header 
"Recognizer-Context-Block" for further details.

Thanks,
Sarvi

---

From: Sarvi Shanmugham <[email-masked]>
Date: Fri, 21 Jan 2005 16:32:01 -0800

After reviewing the IANA considerations guidelines,  the protocol for 
additional values should be as follows. see inline.

>of a working group and not just one expert.

Assignment Protocol: Specification Required

>Assignment protocol: IETF Review
Assignment Protocol: Specification Required

>Assignment protocol: IETF Review

Assignment Protocol: Specification Required

>Assignment protocol: IETF Review

Assignment Protocol: Specification Required

>and thus the  contents are well-known to be
Yes.
Assignment Protocol: Hierarchical allocation
Example: Object Identifiers.

>Assignment protocol: IETF Review

Assignment Protocol: Specification Required

Assignment Protocol: Hierarchical allocation
Example: Object Identifiers.

Thanks,
Sarvi

---

From: Dan Burnett <[email-masked]>
Date: Wed, 26 Jan 2005 10:06:30 -0800 (PST)

I'm not sure I agree with all of your "Specification
Required" Allocation policies, since they require only
an RFC (possibly Informational) rather than a complete
review.  Did you by any chance mean to suggest "IETF
Review", which includes a requirement for an RFC, or
even "Standards Action", the most stringent
requirement?

Also, for the vendor specific parameters you suggested
"Hierarchical Allocation".  I agree with this and
would recommend either "First Come First Served" or
"Expert Review" for the top-level with delegation to
the requester for anything below.

Note that for vendor specific parameters, the draft
says "The vendor-av-pair-name can be any Vendor
specific field name and conforms to the XML
vendor-specific attribute naming convention". 
Unfortunately, I doubt this is sufficiently precise
for IANA.  Can anyone suggest some more complete
specification text for the various vendor-specific
paramaters and IDs in the document?

-- dan

> >http://mobile.yahoo.com/maildemo 
=== message truncated ===

__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com

---

From: Sarvi Shanmugham <[email-masked]>
Date: Wed, 26 Jan 2005 10:33:58 -0800

>even "Standards Action", the most stringent
Requiring an RFC is what I meant. Also this should not be just an 
Informational RFC.  Which  leaves us with the a Standards track RFC 
document.

>the requester for anything below.
ok

Sarvi

>>>In the course of reviewing the draft in order to
>>>      
>>>
>>write
>>    
>>
>>>the IANA Considerations sections, I've identified
>>>      
>>>
>>the
>>    
>>
>>>requesting IANA to maintain a registry.  For each
>>>      
>>>
>>one,
>>    
>>
>>>I've made a suggestion as to whether or not we
>>>      
>>>
>>should
>>    
>>
>>>all remaining value spaces will be that there must
>>>      
>>>
>>be
>>    
>>
>>>I would also like particularly to hear feedback on
>>>      
>>>
>>2
>>    
>>
>>>and 5, below, since my suggested assignment
>>>      
>>>
>>protocol
>>    
>>
>>>Comment: This is a core part of the spec and
>>>      
>>>
>>requires
>>    
>>
>>>significant understanding and industry consensus.
>>>      
>>>
>>The
>>    
>>
>>>introduction of a new resource should require
>>>      
>>>
>>approval
>>    
>>
>>>methods without creating a whole new version of
>>>      
>>>
>>MRCP. 
>>    
>>
>>>Comment: This is unlikely to change.  If there were
>>>      
>>>
>>a
>>    
>>
>>>Comment:  This is the sort of thing that might need
>>>      
>>>
>>to
>>    
>>
>>>be adjusted based on further implementation
>>>      
>>>
>>experience
>>    
>>
>>>by the industry.  It should not require a re-write
>>>      
>>>
>>of
>>    
>>
>>>the spec, but any additions would need to be
>>>      
>>>
>>reviewed
>>    
>>
>>>way, I would recommend that we include a small
>>>      
>>>
>>number
>>    
>>
>>>of codes specifically for experimental use (see
>>>      
>>>
>>[2]).
>>    
>>
>>>events without creating a whole new version of
>>>      
>>>
>>MRCP. 
>>    
>>
>>>headers without creating a whole new version of
>>>      
>>>
>>MRCP. 
>>    
>>
>>>identified by the "Vendor-Specific-Parameters"
>>>      
>>>
>>prefix
>>    
>>
>>>Comment: This one I'm not sure about.  It's similar
>>>      
>>>
>>to
>>    
>>
>>>provide a slot for such extensions (i.e. the list
>>>      
>>>
>>is
>>    
>>
>>>extensions here should match that for 2 and 5,
>>>      
>>>
>>whether
>>    
>>
>>>we permit extensions for all (without a new MRCP
>>>      
>>>
>>spec)
>>    
>>
>>>Comment: Although I think there might be some use
>>>      
>>>
>>in
>>    
>>
>>>having a registry for each, it seems like overkill
>>>      
>>>
>>to
>>    
>>
>>>Take Yahoo! Mail with you! Get it on your mobile
>>>      
>>>
>>phone. 
>>    
>>