On 3/5/2017 6:35 PM, John Levine wrote:
Again, my concern is with handing IANA an on-going task -- making a
check every time they update the Attrleaf table -- that requires their
being perfect at detecting collisions with one or more other tables.
Has anyone asked IANA whether they have an opin
In article <654358a9-10a9-52f3-c1e9-5f6e3392f...@dcrocker.net> you write:
For URI records RFC 7553 says they're either named the same as SRV
records, or they use enumservice names from the Enumservice
>> Patrik's and John 's postings notwithstanding, I'm still concerned about
>> the prop
Hi, folks,
I've been reminded that the attrleaf draft is still pending. I've
re-submitted the -00 draft as -01, just to restart the timer on the
document.
On reviewing the discussion history, I see some items for the list that
I believe weren't resolved...
On 8/28/2016 4:04 PM, Dave Croc
First, when creating the URI RR I felt a registry WAS needed. The mess with SRV
could not be accepted.
RFC 6335 cleaned up the SRV mess pretty completely.
1. Merge of all sources we have, i.e. what will the initial list of prefixes
look like?
2. When adding things to this table, what is real
On 29 Aug 2016, at 3:42, John Levine wrote:
For URI records RFC 7553 says they're either named the same as SRV
records, or they use enumservice names from the Enumservice
>
>>> Declaring a namespace as the union of two, independently-maintained
>>> registries is a very efficient way to e
On 8/28/2016 8:15 PM, Paul Hoffman wrote:
Simply put, specifying a smal task that requires humans to perform
perfectly at random, very (very) infrequent times, is a plan designed
to fail.
Can't this be checked by scraping IANA on a daily basis? That is, if
IANA makes a mistake, it will be dete
On 28 Aug 2016, at 18:58, Dave Crocker wrote:
On 8/28/2016 6:42 PM, John Levine wrote:
atrik's and John 's postings notwithstanding, I'm still concerned
about
>the proposed way of handling this, namely to rely on IANA to do a
manual
>check of the two registries the URI RR might call on. First
On 8/28/2016 6:42 PM, John Levine wrote:
atrik's and John 's postings notwithstanding, I'm still concerned about
>the proposed way of handling this, namely to rely on IANA to do a manual
>check of the two registries the URI RR might call on. First, it does
>not seem reasonable to me to impose th
>> So after going through all that and then looking at RFC 6335, including
>> its assorted references to support for SRV, I gather the IANA table in
>> question is:
>>
>>Service Name and Transport Protocol Port Number Registry
>
>And the draft -attrleaf- needs to point to this, I believe.
So f
Folks (including Patrik)...
Hi.
Checking on where group views are, now that some exchanges have happened
and time has passed...
On 8/3/2016 8:48 PM, Dave Crocker wrote:
And now, my response to John's note...
On 8/3/2016 6:58 PM, John Levine wrote:
The services, on the other hand, were tho
Patrik,
> On Aug 9, 2016, at 12:06 PM, Patrik Fältström wrote:
>
> On 4 Aug 2016, at 18:55, Dave Crocker wrote:
>
For URI records RFC 7553 says they're either named the same as SRV
records, or they use enumservice names from the Enumservice
>>>
>>> Declaring a namespace as the union
On 4 Aug 2016, at 18:55, Dave Crocker wrote:
>>> For URI records RFC 7553 says they're either named the same as SRV
>>> records, or they use enumservice names from the Enumservice
>>
>> Declaring a namespace as the union of two, independently-maintained
>> registries is a very efficient way to enc
On 8/4/2016 1:54 AM, Ray Bellis wrote:
The one I thought was a deviation was "xmpp-client" (5222), but it turns
out that's just because my macOS /etc/services file is out of date and
still lists that as "jabber-client".
Thanks for the clarification, Ray.
Absent anyone else raising concerns, I'
On 04/08/2016 05:05, John R Levine wrote:
> As of Berlin, I thought I heard that there was (still) deviations.
The one I thought was a deviation was "xmpp-client" (5222), but it turns
out that's just because my macOS /etc/services file is out of date and
still lists that as "jabber-client".
Ra
If folks agree that this [RFC6355] adequately serves the registry
function for the
_service, second-level underscore name for SRV and URI, that's fine.
As of Berlin, I thought I heard that there was (still) deviations.
I can believe it, but as I suggested, if that's the case, register the
rog
And now, my response to John's note...
On 8/3/2016 6:58 PM, John Levine wrote:
The services, on the other hand, were thoroughly cleaned up by RFC
6335. It collected a bunch of informal lists into one place, renamed
a few old names with unfortunate characters, and put them into a tidy
and very
16 matches
Mail list logo
