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

From: "Reifenrath, Klaus" <[email-masked]>
Date: Mon, 24 Jan 2005 07:21:09 -0500

Hi Dan,

will you also write the IANA considerations for application/x-nlsml and the
following SDP related entries?	
media type:
- application/mrcpv2
- control
NOTE: According to draft-ietf-mmusic-sdp-new-23.txt (sections 8.2.1) the
media type "control" is deprecated!
attribute field names:
- resource
- channel
protocol identifier (probably need to be coordinated with the MMUSIC group):

- SCTP
- TLS

At the last F2F meeting in San Diego we discussed caller preference-based
SIP routing, which most likely would require some more IANA registrations.
 
Best regards,
Klaus

-----Original Message-----
From: Dan Burnett [mailto:[email-masked]]
Sent: Freitag, 21. Januar 2005 19:52
To: [email-masked]
Subject: [Speechsc] IANA considerations for group feedback

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-rfc2434
bis-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

---

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

Just to make sure it should no longer be x-nlsml if we are standardizing it.
>From IANA:

A server MUST NOT offer unregistered or non-standard capability names,
unless such names are prefixed with an "X".

More specifically:
Begin with "x-": Private use. Begin with "e-": Experimental use, registered
FCFS. All others: Expert review.

-Tom

[email-masked]  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Reifenrath, Klaus
> Sent: Monday, January 24, 2005 4:21 AM
> To: 'Dan Burnett'
> Cc: [email-masked]
> Subject: RE: [Speechsc] IANA considerations for group feedback
> 
> Hi Dan,
> 
> NOTE: According to draft-ietf-mmusic-sdp-new-23.txt (sections 
> 8.2.1) the media type "control" is deprecated!
> attribute field names:
> - resource
> - channel
> At the last F2F meeting in San Diego we discussed caller 
> preference-based SIP routing, which most likely would require 
> some more IANA registrations.
>  
> Best regards,
> Klaus
> 
> 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
> 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?
> 
> 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.
> 
> 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
> 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]

---

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

I agree that there needs to be an registration of
application/x-nlsml (or, as an email from Tom pointed
out, application/nlsml).  Technically it should be in
a separate RFC from MRCP, but I can include it in the
draft if there are no objections.

If "control" is already registered, do we need to do
it?  In short, it's not clear to me in which
namespace(s) the SDP items you mention should be
registered.  Are they new namespaces for MRCP or are
there existing namespaces to which the items should be
added?

-- dan

--- "Reifenrath, Klaus"

---

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

I have some concerns with this.  In one of my other
recent responses I said I would be happen to include a
registration for application/nlsml in the draft, but I
would still prefer for that registration to occur
independently since we don't own the NLSML draft.

This ugly beast has raised its head many times. 
speechsc does not own NLSML but has adopted it (for
reasons too convoluted to review in this email). 
There was never a MIME type registered for it.

Eric, Dave, what do you think?  Should we register
application/nlsml as part of MRCP, register
application/nlsml separately, or leave things as they
are and refer to application/x-nlsml?

-- dan
p.s. now I know why Eric and Dave wanted someone else
to volunteer :)

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

> > NOTE: According to
> draft-ietf-mmusic-sdp-new-23.txt (sections 
> > protocol identifier (probably need to be
> coordinated with the 
> > MMUSIC group):
> > 
> > - SCTP
> > - TLS
> > 
> these, 
> identified by 
> provide a 
http://www.ietf.org/internet-drafts/draft-narten-iana-consider
> > ations-rfc2434
> > bis-01.txt
> > [2]
> ftp://ftp.rfc-editor.org/in-notes/bcp/bcp82.txt
> 
=== message truncated ===

__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com

---

From: "Thomas Gal" <[email-masked]>
Date: Wed, 26 Jan 2005 11:47:47 -0800

[email-masked]

-Tom

[email-masked]  

> [mailto:[email-masked]] On Behalf Of Dan Burnett
> Sent: Wednesday, January 26, 2005 10:15 AM
> To: Reifenrath, Klaus
> Cc: [email-masked]
> application/x-nlsml (or, as an email from Tom pointed out, 
> application/nlsml).  Technically it should be in a separate 
> RFC from MRCP, but I can include it in the draft if there are 
> no objections.
> 

I would certainly agree with not using "application/nlsml" but something
similar to obviate confusion, even mrcp-nlsml or something.

> If "control" is already registered, do we need to do it?  In 
> short, it's not clear to me in which
> namespace(s) the SDP items you mention should be registered.  
> Are they new namespaces for MRCP or are there existing 
> namespaces to which the items should be added?
> 

Isn't MRCPv2 "control"? I would guess control is too ambiguous and probably
why it's being deprecated.

-Tom

---

From: Sarvi Shanmugham <[email-masked]>
Date: Wed, 26 Jan 2005 16:48:03 -0800

We have included a version of the NLSML specification within this MRCPv2 
specification with the  permission from the W3C.
So I think it is appropriate that we regsiter application/nlsml with 
this specification, as this will be the first public 
standard/specification of NLSML.

The W3C, will ofcourse evolve the spec in the future, and this should 
not pose a problem.

Thx,
Sarvi
Dan Burnett wrote:

>>>[mailto:[email-masked]] On Behalf Of
>>>      
>>>
>>Reifenrath, Klaus
>>    
>>
>>>Subject: RE: [Speechsc] IANA considerations for
>>>      
>>>
>>group feedback
>>    
>>
>>>Hi Dan,
>>>
>>>At the last F2F meeting in San Diego we discussed
>>>      
>>>
>>caller 
>>    
>>
>>>preference-based SIP routing, which most likely
>>>      
>>>
>>would require 
>>    
>>
>>>From: Dan Burnett
>>[mailto:[email-masked]]
>>    
>>
>>>Subject: [Speechsc] IANA considerations for group
>>>      
>>>
>>feedback
>>    
>>
>>>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 
>>    
>>
>>>I would also like particularly to hear feedback on
>>>      
>>>
>>2 and 5, 
>>    
>>
>>>below, since my suggested assignment protocol may
>>>      
>>>
>>be quite 
>>    
>>
>>>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 
>>    
>>
>>>2. Name space: extension methods (sec. 5.1) IANA
>>>      
>>>
>>registry?: 
>>    
>>
>>>Comment: It should be possible to extend the set
>>>      
>>>
>>of methods 
>>    
>>
>>>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.
>>>
>>>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 
>>    
>>
>>>5. Name space: extension events (sec. 5.3) IANA
>>>      
>>>
>>registry?: 
>>    
>>
>>>Comment: It should be possible to extend the set
>>>      
>>>
>>of events 
>>    
>>
>>>6. Name space: extension headers (sec. 6.1) IANA
>>>      
>>>
>>registry?: 
>>    
>>
>>>Comment: It should be possible to extend the set
>>>      
>>>
>>of headers 
>>    
>>
>>>the "Vendor-Specific-Parameters" prefix and thus
>>>      
>>>
>>the  
>>    
>>
>>>8. Name space: parameter list (sec. 6.2/6.3) IANA
>>>      
>>>
>>registry?: 
>>    
>>
>>>Comment: This one I'm not sure about.  It's
>>>      
>>>
>>similar to
>>    
>>
>>>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 
>>    
>>

---

From: "Thomas Gal" <[email-masked]>
Date: Wed, 26 Jan 2005 16:53:40 -0800

So you're saying it's not been deprecated [in favor of EMMA]?

-Tom

[email-masked]  

> The W3C, will ofcourse evolve the spec in the future, and 
> this should not pose a problem.
> 
> Thx,
> Sarvi

---

From: Sarvi Shanmugham <[email-masked]>
Date: Wed, 26 Jan 2005 20:49:14 -0800

I meant to say W3C "will have the option to" evolve.

Sarvi

---

From: David R Oran <[email-masked]>
Date: Thu, 27 Jan 2005 13:36:22 -0500

> are and refer to application/x-nlsml?
I think either will have some difficulties convincing the PWB, but I 
think we could get either through. I'd hedge bets and put in words in 
the IANA considerations asking them to register one OR THE OTHER at 
their discretion.

> === message truncated ===
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "Thomas Gal" <[email-masked]>
Date: Thu, 27 Jan 2005 13:20:59 -0800

YOU DON'T REGISTER SOMETHING WITH AN "X-", IT'S JUST SYNTAX FOR UNREGISTERED
ITEMS.

RFC 2045:

"Private values (starting with "X-") may be defined bilaterally between two
cooperating agents without outside registration or standardization. Such
values cannot be registered or standardized."

And RFC 2048:

"Proposed media types are not formally registered and must not be used; the
"x-" prefix specified in RFC 2045 can be used until registration is
complete."

Does that clear it up?

I also personally want to note that I think putting forth a suggestion like
below which embodies "pass the buck" and doesn't make a decision is always a
BAD idea. Even worse "to get it through xxxx" should never be the
justification for a decision in any case, because it has no bearing on what
we're here to do. Especially for a standards body whose purpose is to
evaluate competing proposals to make a choice for the best. Especially as in
this case where there was a clear answer that appears to have been glossed
over for whatever reason.

-Tom

[email-masked]  

> > I have some concerns with this.  In one of my other recent 
> responses I 
> > said I would be happen to include a registration for 
> application/nlsml 
> > in the draft, but I would still prefer for that 
> registration to occur 
> > speechsc does not own NLSML but has adopted it (for reasons too 
> > convoluted to review in this email).
> application/nlsml 
> > as part of MRCP, register application/nlsml separately, or leave 
> > things as they are and refer to application/x-nlsml?
> >
> I think either will have some difficulties convincing the 
> PWB, but I think we could get either through. I'd hedge bets 
> and put in words in the IANA considerations asking them to 
> register one OR THE OTHER at their discretion.
> 
> > -- dan
> > p.s. now I know why Eric and Dave wanted someone else to 
> volunteer :)
> >
> >