- From: Al Gilman <asgilman@iamdigex.net>
- Date: Sun, 28 Jan 2001 23:08:38 -0500
- To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>, "Weibel,Stu" <weibel@oclc.org>
- Cc: "'michaelm@netsol.com'" <michaelm@netsol.com>, Aaron Swartz <aswartz@swartzfam.com>, Larry Masinter <masinter@adobe.com>, uri@w3.org, ietf-type@iana.org, dee3@torque.pothole.com, Graham Klyne <GK@ninebynine.org>, Ted Hardie <hardie@equinix.com>
I never caught up with the requirement being addressed, here. What does CC/PP actually do with types that it hears about? What does it need to know about a type? What is the range of types it would come in touch with? Does it ever compare a type and an instance for conformance? Or does it compare type references for equivalence? What types would one hard-code into CC/PP? Or are the types not protocol parameters, but rather protocol data in CC/PP? It seems to me it would make more sense to create a schema which documents the structure of the Internet Media Type space. Then reference Internet Media Types via their place in this schematized index to the existing dictionary of types. Does CC/PP need to know that text/* is a supertype of text/html and of text/plain? Does it need to know that application/octet-stream is a supertype of application/anything-else? If it does, just injecting each type-indication (header field value) into URI space as an unrelated atom loses a lot of the value of the Internet Media Type system. Al At 10:15 PM 2001-01-28 -0500, Donald E. Eastlake 3rd wrote: > >From: "Weibel,Stu" <weibel@oclc.org> >Message-ID: <A4DCD9B43F237A41BE31C98D434C22880B5EE9@OA4-SERVER.oa.oclc.org> >To: "'michaelm@netsol.com'" <michaelm@netsol.com>, > Aaron Swartz > <aswartz@swartzfam.com> >Cc: Larry Masinter <masinter@adobe.com>, > "Donald E. Eastlake 3rd" > <dee3@torque.pothole.com>, uri@w3.org, > Graham Klyne <GK@ninebynine.org>, Ted Hardie <hardie@equinix.com> >Date: Sun, 21 Jan 2001 09:26:57 -0500 > >>URLs that are responsibly constructed and well managed will be as persistent >>as the committment of the organizations that manage them. > >That isn't true, as an orgnaization's DNS names can get taken away >from them due to conflicts of which they were not originally aware. >But even if it were true, many organizations change name and/or domain >name for marketing reasons, because new management wants to make a >change, because old management wants to appear to be making a change, >etc. > >It makes no sense to me to have the stability of MIME Type / >Content-Type <-> URI mappings to depend on the name stability and duty >assignment stability of IANA or ICANN or the IETF or W3C. This >mapping will get embedded into widely deployed code, essentially >impossible to get globally updated. > >Donald > >>The vulnerabilities discussed in these messages simply don't pertain to well >>managed URLs (that is, managed according to publically stated policies and >>with reasonable attention to IPR issues). >> >>stu >> >>-----Original Message----- >>From: Michael Mealling [<mailto:michael@bailey.dscga.com%5D>mailto:michael@bailey.dscga.com] >>Sent: Sunday, January 21, 2001 3:26 AM >>To: Aaron Swartz >>Cc: Larry Masinter; Donald E. Eastlake 3rd; uri@w3.org; Graham Klyne; >>Michael Mealling; Ted Hardie >>Subject: Re: comments on draft-eastlake-cturi-01.txt >> >>On Sun, Jan 21, 2001 at 12:21:26AM -0600, Aaron Swartz wrote: >>> Larry Masinter <masinter@Adobe.COM> wrote: >>> > That you, Aaron Swartz, do not see the need to use anything >>> > other than "<http://www.iana.org/>http://www.iana.org", which has sufficient >>> > stability for your own purposes, doesn't mean that it will >>> > meet the needs of everyone else. >>> > >>> > I suppose this argument will persist until we resolve >>> > the W3C/IETF split over the utility of URNs and their >>> > role in protocol element identification. >>> >>> I hate to see this argument pointlessly persist, so I will stop arguing >>> after this question: >>> >>> Why aren't my URLs safe? That is, why do I have to worry about an address >>at >>> iana.org suddenly disappearing one day? What needs are not met by this >>> system? >> >>>From my standpoint there are two reasons: >> >>One of the main reasons is that due to existing case law you >>don't own your domain-name (the same way you don't own your telephone >>number). If a court says so a registry is required to remove that >>domain-name from service and either not give it back out to anyone or >>sell it to someone (probably a competitor). >> >>Reason two: since there is nothing inherent to domain-names or >>http or anything else, the only way I know I can use your >>URLs anytime beyond tomorrow afternoon is that you have told me so. >>That may be fine if I interact with you on a daily basis but >>if I come across some URI 'in the wild' I have no idea how >>persistent it may be and if I do act as though it were useable >>beyond tomrrow afternoon then _I_ am the one making an error in >>assumptions. Now, if the URI scheme requires that it be persistent >>then I can start doing some pretty powerful things since I can >>now make that assumption safely. If the URI I find 'in the wild' >>is part of that scheme and it doesn't follow those rules then >>I know that it is an error in the network, not in my making >>erroneous assumptions.... >> >> >>> I use URLs for a lot of the work I do and I'm curious whether I'm making a >>> mistake. >> >>Probably not for most cases. But if you plan on using a URI 10 or 20 >>years from now it just might be a problem. Heck, there was a large amount >>of discussion at the last IETF about creating a new DNS class >>and changing the rules _completely_ (in a new class you don't >>have to follow any of the old rules, including delegation models). >> >>-MM >> >>---------------------------------------------------------------------------- >>Michael Mealling | Vote Libertarian! | >><http://www.rwhois.net/michael>www.rwhois.net/michael >>Sr. Research Engineer | <http://www.ga.lp.org/gwinnett>www.ga.lp.org/gwinnett | ICQ#: >>14198821 >>Network Solutions | <http://www.lp.org/>www.lp.org | >>michaelm@netsol.com >
Received on Sunday, 28 January 2001 22:58:01 UTC