Subject: RE: [Speechsc] IANA considerations for group feedback

From: Ken Robbins <[email-masked]>
Date: Mon, 24 Jan 2005 10:38:49 -0500

Dan,
Should the treatment of the related MIME types be part of your value space
discussion or do you already have this covered?

I've included a list of MIME types that I found in the draft, with my
comments added:

application/mrcpv2
     IANA application required.

application/synthesis+ssml
application/srgs+xml
application/srgs
     W3C Voice Browser Working Group has already applied for these, but they
are not yet listed as registered by IANA.

application/sml
     Appears on page 139. Is this a typo?

application/x-nlsml
     Not IANA registered. Do "x-" subtypes need to be?

application/octets
     Not IANA registered. Note that octet-stream is registered. Do we mean
octets or octet-stream?

Ken Robbins
Brooktrout Technology, Inc.

-----Original Message-----
From: Sarvi Shanmugham [mailto:[email-masked]] 
Sent: Friday, January 21, 2005 3:31 PM
To: Dan Burnett
Cc: [email-masked]
Subject: Re: [Speechsc] IANA considerations for group feedback

comments line.
Dan Burnett wrote:

>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.
>  
>
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.

>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?
>  
>
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.

>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.
>  
>
agreed.

>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]).
>  
>
agreed.

>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?
>  
>
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.

>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?
>
>  
>
Agreed.

>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.
>  
>
The question then is how is the server or client to recognize which 
vendors resource it is and hence what parameters it supports?

>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).
>  
>
Yes this should also be extensible.

>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.
>  
>
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

>-- Dan
>
>[1]
>http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc243
4bis-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
>
>  
>

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

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

---

From: "Thomas Gal" <[email-masked]>
Date: Tue, 25 Jan 2005 07:42:08 -0800

Inline

-Tom

[email-masked]  

>      Appears on page 139. Is this a typo?

	I think it's page 138 and it's a speak command so it's gotta be
nlsml.

>      Not IANA registered. Do "x-" subtypes need to be?

	I think items prefaces with "x-" are specifically precluded from
IANA as experimental by notation. I think this was a vestige of it's
previous status(abandoned/incomplete) with the W3C, and should be just
application/nlsml or something else along those lines. In fact it would be
good to alleviate confusion with the W3C spec, as well as indicate that
we've finalized it.

> application/octets
>      Not IANA registered. Note that octet-stream is 
> registered. Do we mean octets or octet-stream?
> 

	I don't think we need to register octets or octet stream really as
this is a functional "catch-all" in the spec meant to indicate anything
specifically uninterrupted or opaque, like a recognizer context block. Even
where we specify the message body as *OCTET it's not really just that but
will end up being an actual mime-type which is supported by the recognizer.
These should obviously all be specified, but octet is just a place holder
here. As for the lexical usage in various parts of the grammar I don't think
that's important from this perspective either.

> >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.
> >  
> >
> 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.
> 
> >2. Name space: extension methods (sec. 5.1) IANA registry?: yes 
> >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?
> >  
> >
> 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.
> 
> >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.
> >  
> >
> agreed.
> 
> >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]).
> >  
> >
> agreed.
> 
> >5. Name space: extension events (sec. 5.3) IANA registry?: yes 
> >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?
> >  
> >
> 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.
> 
> >6. Name space: extension headers (sec. 6.1) IANA registry?: yes 
> >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?
> >
> >  
> >
> Agreed.
> 
> >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.
> >  
> >
> The question then is how is the server or client to recognize 
> which vendors resource it is and hence what parameters it supports?
> 
> >8. Name space: parameter list (sec. 6.2/6.3) IANA registry?: yes 
> >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.
> >  
> >
> The meaning of Completion Cause resource specific. Hence I 
> think future resources, if any, would define their own list of values.

---

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

application/sml is supposed to be
application/synthesis+xml.  It was a typo that
originally should have been application/ssml.

--- Thomas Gal <[email-masked]> wrote:

> these, 
> > does not make it any more easy or difficult to add
> new 
> > resource types. 
=== message truncated ===