|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Gorry Eddie Kohler wrote:
That was the proposal - I can see merits in human-readable approaches, so that would also be fine to discuss.Gorry Fairhurst wrote:Tom,Thanks for your comments. I am working through them, and it looks like these will improve the I-D. I'll send a detailed response later.One thing you said is specifically something that I'd like to discuss at the meeting tomorrow:"I don't like the idea of making the service name from the hexadecimal value of the Service Code. It seems to me that service names are meant to human readable, and the hex value is anything but."I completely agree with Tom; and I do not see any need to derive port registration names from DCCP service codes.
* There's a catch. If we wanted "easy" assignment of Server Ports (with minimal IANA review), we could not expect the IANA to allow easy arbitrary allocation to the proposed ServName registry, where these entries need to be unique across all protocols. So, how could we offer ServNames that would be simple to allocate?Do you mean PORT names here?
Port names do not need to be unique across all protocols.
> We can check with Michel today, she'll be present in the meeting.
They are not currently.
> True - but I thought that *was* the intention.
You mean something more specific, I think. What is it? It seems reasonable to me that ports be allocated relatively slowly. Eddie* It would be nice to have a fixed format that could be automatically generated. We could allow e.g. SCfoob - but this would not support non-ASCII SC's. The SC is a 32-bit number, so not all have an ASCII representation. If we relaxed this, we could allow two formats e.g. SCfoob and SC0x4543484f. Ideas?* If we can figure out how to easily create entries, DCCP could ask IANA to reserve the block of names with a specific prefix, e.g. "0x", "SC" or whatever. Thoughts?Let's discuss. I would really like to resolve this soon. Gorry