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

From: "Reifenrath, Klaus" <[email-masked]>
Date: Mon, 24 Jan 2005 11:24:08 -0500

The URI scheme "session" requires IANA registration (see RFC2396,RFC1738).

Klaus
-----Original Message-----
From: Reifenrath, Klaus [mailto:[email-masked]]
Sent: Montag, 24. Januar 2005 13:21
To: 'Dan Burnett'
Cc: [email-masked]
Subject: RE: [Speechsc] IANA considerations for group feedback

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

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

---

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

This is a good point.  Unfortunately, I don't think we
defined this scheme sufficiently for me to write such
registration.  Suggestions, anyone?

-- dan

--- "Reifenrath, Klaus"

		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail

---

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

I thought it was pretty well defined as being lexically:

"session:uri". Beyond that it's persistence is only guaranteed for the
session, and can be overwritten  by using the same URI for another item. I
don't think there's really anything else to define.....

RFC 2396 ( and the obsoleted 1738) is about syntax of URLs so they don't
really have bearing, unless you were referring to that as the issue....as
for registration it seems to be pretty well covered in 2717 and 2718. 2717
explaining the registration process or dare I say protocol, and 2718
explaining the necessary rational for syntax of an extension URI scheme.

SO is the question the exact format of the URI because the synatx in the
MRCPv2 document is more or less standard down to some minor details?

Otherwise the factors enumerated from the RFC for appropriatness with some
comments:

2.1 Syntactic compatibility

   New URL schemes should follow the same syntactic conventions of
   existing schemes when appropriate.  

	-Again I know that the only real differences are in quoted text and
some minor details at the bottom of the syntax tree that are just
simplifications of 

2.1.1 Motivations for syntactic compatibility

   Why should new URL schemes share as much of the generic URI syntax
   (that makes sense to share) as possible? 

	-Basically the reality here is that MRCP is a part of the grander
scheme of VXML and the web itself and URLs will often be embedded in a
diverse set of other types of resources so this justifies syntactic
similarity quite well.

2.1.2 Improper use of "//" following "<scheme>:"

	-We do have the authority directly following the slashes as
specified.

2.1.3 Compatibility with relative URLs

   	URL schemes should use the generic URL syntax if they are intended
to
   	be used with relative URLs. 

	- We are using the generic URL syntax more or less

2.2 Is the scheme well defined?

	-grammars markup etc in our context we've specified in which
messages this scheme can be used

2.2.1 Clear mapping from other name spaces

	-Doesn't really appear to be an issue

2.2.2 URL schemes associated with network protocols
	For such schemes, the specification should completely describe how
URLs are
      translated into protocol actions in sufficient detail to make the
      access of the network resource unambiguous. 

	-I think we've defined this pretty well

2.2.3 Definition of non-protocol URL schemes

	-This is a protocol URL

2.2.4 Definition of URL schemes not associated with data resources

	-These URLs are specifically associated with data in the cotext of
the protocol

2.2.5 Character encoding

	-Section 5 says MRCPv2 is ISO 10646/UTF-8, and the MRCPv2 headers
are limited to US-ASCII. SO this may be a little bit ambiguous and I would
propose that we limit this to US-ASCII as well as these urls are for local
reference, and human readability is not important. Really since these values
appear in headers of the protocol they are more or less already definced to
be US-ASCII.

2.2.6 Definition of operations

	-Yes this is very clear.

2.3 Demonstrated utility

	-Obviously it's nice to have a way to referrence intermediate
objects in this protocol. I don't think anyone will dispute the utility.

2.4 Are there security considerations?

	-I would hope we don't need a security considerations section for
the iana section :)

I think we've pretty well covered it in the document, it may just need to be
clarified or put into a second document. Certainly the notion of a session
"scoped" uri could be helpful and applicable in other areas and protocols as
well.

- -Tom

[email-masked]  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dan Burnett
> Sent: Wednesday, January 26, 2005 10:18 AM
> To: Reifenrath, Klaus
> Cc: [email-masked]
> > 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
> > 
> > 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 
> > 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 
> > 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 
> > 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 
> > 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 
> > 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]
> >