Reinaldo, I don't think the current ALTO draft is that permissive. Section 6.6.5 (Cost Types) seems to require that a server register any cost type that doesn't start with "exp:":
> Identifiers prefixed with ¹priv:¹ are reserved for Private Use > [RFC5226]. Identifiers prefixed with ¹exp:¹ are reserved for > Experimental use. All other identifiers appearing in an HTTP request > or response with an ¹application/alto-*¹ media type MUST be > registered in the ALTO Cost Types registry Section 9.2. > Also, although we've registered "routingcost" with IANA, I don't consider that cost type is "interoperable." To me, "interoperable" means that "routingcost" values would be comparable between servers, so that a cost of (say) 40 means the same on all ALTO servers. That's clearly not the case. Nor should it be! Perhaps I'm missing the point, but as long as an ALTO server has a standard way to describe its cost types, I don¹t see any advantage to registering ALTO cost types with the IANA. - Wendy > Date: Thu, 21 Feb 2013 16:00:30 +0000 > From: "Reinaldo Penno (repenno)" <[email protected]> > > Hello, > > Some comments inline... > > From: Wendy Roome > <[email protected]<mailto:[email protected]>> > Date: Wed, 20 Feb 2013 09:49:17 -0500 > > .... > > 3. Your last point is about registering cost types. Yes, my proposal would > make it harder to register new cost types with the IANA. > > But I'll turn that around. Why do we need a central registry for cost types at > all? Why does the IANA need to control them? Sorry if I'm stepping on > someone's favorite idea here, but to me, a central registry seems totally > unnecessary. Worse than that, it's harmful: it will stifle innovation, by > making it much harder to create and experiment with new cost types. > > [RP] You can always define a new cost type and experiment with it. IANA > registered means standardization and interop are required. > > Yes, that means that two independently implemented ALTO servers can each > define a new cost type named "myExtendedCost", with completely different > semantics. So what? What's the problem with that? Clients will know that > "myExtendedCost" is only meaningful within the context of a specific ALTO > server. > > Note that the cost type extension I proposed takes over the descriptive > features of the IANA registry, in that it provides all the information about > this new cost type that a potential client needs to know. It doesn't allow the > IANA to manage and control new cost types. But I think that's a good thing! > > So in short, I suggest dropping the central "cost type registry" requirements > completely (Section 9.2). Instead, the ALTO server provides a description of > its cost types in its resource directory. ALTO servers are free to invent new > cost types, to differentiate themselves and provide additional value. > > [RP] ALTO servers can already do that today. IANA registration does not > preclude any of that, and as you say, within a domain you can define whatever > cost mode you want. This is not new, IANA registers a few modes/message > types/etc and reserves some for private use. > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
