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

From: Dan Burnett <[email-masked]>
Date: Wed, 9 Feb 2005 06:53:33 -0800 (PST)

It appears that the syntax for the URLs in this scheme
is intended to be identical to that for the "cid"
scheme (see "Content-Id").  Is there any way we can
make use of the existing "cid" scheme rather than
defining our own?

By the way, RFC2111 (reference 15) was obsoleted by
RFC2392.

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

> 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]  
> 
> > -----Original Message-----
> > 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]
> > Subject: RE: [Speechsc] IANA considerations for
> group feedback
> > 
> > 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"
> > <[email-masked]> wrote:
> > 
> > > 
> > > 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
> 
=== message truncated ===

> ATTACHMENT part 2 application/x-pkcs7-signature
name=smime.p7s

__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250

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

---

From: Dan Burnett <[email-masked]>
Date: Thu, 10 Feb 2005 06:03:50 -0800 (PST)

Thanks.  The registration process requires a
discussion of what resources can be accessed via the
scheme.  Can you (or anyone else on the list) comment
on how, if at all, the media type of the resource
pointed to by this scheme is known?  Although
currently we only have a restricted number of resource
types (grammars, lexicons, etc.), I can't find any
indication of how the type would make its way back to
the user.  Unlike the "http" scheme, there isn't much
of a protocol definition in our spec.  I believe the
protocol definition is limited to "the resource may be
accessed via the scheme".

Any thoughts?

-- dan

name=smime.p7s

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

---

From: Dan Burnett <[email-masked]>
Date: Thu, 10 Feb 2005 07:04:29 -0800 (PST)

Never mind.

		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail