This is what you need. A private cost you can use within your ALTO servers and 
domain.

"Identifiers prefixed with ’priv:’ are reserved for Private Use"



From: Wendy Roome 
<[email protected]<mailto:[email protected]>>
Date: Thu, 21 Feb 2013 11:32:03 -0500
To: <[email protected]<mailto:[email protected]>>
Subject: Re: [alto] Discussion II: Unifying cost-mode and cost-type to a single 
type

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]<mailto:[email protected]>>

Hello,

Some comments inline...

From: Wendy Roome 
<[email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to