Subject: Content-Id (was RE: [Speechsc] IANA considerations for group feed back)

From: Eric Burger <[email-masked]>
Date: Mon, 28 Feb 2005 15:25:13 -0500

This is exactly what Content-Id is for.  Good catch!

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Dan Burnett
> Sent: Wednesday, February 09, 2005 9:54 AM
> To: [email-masked]; 'Reifenrath, Klaus'
> Cc: [email-masked]
> Subject: RE: [Speechsc] IANA considerations for group feedback
> 
> 
> 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
> 

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