Subject: Re: [Gen-art] Gen-ART review of draft-ietf-speechsc-mrcpv2-24.txt

From: Dan Burnett <[email-masked]>
Date: Sun, 30 Oct 2011 21:19:34 -0400

On Jul 19, 2011, at 3:27 AM, Miguel A. Garcia wrote:

> Hi Dan:
> 
> I have some further discussions on a couple of comments. I have deleted from this e-mail all those comments for which no more discussion is needed.
> 
> On 12/07/2011 1:40, Dan Burnett wrote:
>> Miguel,
>> 
>> Thank you for your comments. I have replied to each with either the
>> action I intend to take or the reason why I believe a change is not
>> warranted at this time, with one exception.
>> 
>> There is one item below, regarding the Vendor Parameters registry, which
>> is still under discussion.
>> 
>> Draft-25, which I will post in a few minutes, addresses the comments that
>> I say below that I will address.
>> It does not address all of the draft-24 review comments received from
>> others, so there will be another draft after the IETF 81 publication
>> moratorium expires.
>> 
>> -- dan
>> 
>> On May 3, 2011, at 2:39 AM, Miguel A. Garcia wrote:
>> 
>>> I have been selected as the General Area Review Team (Gen-ART)
>>> reviewer for this draft. For background on Gen-ART, please see the FAQ at
>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>>> 
>>> Please resolve these comments along with any other comments you may
>>> receive.
>>> 
>>> Document: draft-ietf-speechsc-mrcpv2-24.txt
>>> Reviewer: Miguel Garcia <[email-masked]
>>> <mailto:[email-masked]>>
>>> Review Date: 2011-05-03
>>> IETF LC End Date: 2011-04-13
>>> 
>>> Summary: The document is on the right track, but has some issues that
>>> should be addressed before publication as a standards track RFC.
>>> 
>>> Major issues: none
>>> 
>>> Minor issues:
>>> 
>>> - Section 4.2 reads:
>>> 
>>> To remain backwards compatible with conventional SDP usage,
>>> the format field of the m-line MUST have the arbitrarily-selected
>>> value of "1".
>>> 
>>> The comment is that in other protocols, for example, MSRP [RFC4975] it
>>> has been selected to use an asterisk "*" in the format field. I wonder if
>>> it is possible to unify criteria, in order to allow usage of conventional
>>> SDP parsers.
>> 
>> I don't see how this has any relationship to "conventional SDP parsers".
>> Any SDP parser should be able to parse the value "1", and the allowed
>> value is protocol-specific anyway. Since the values of the media and
>> protocol fields are completely different in our case, and because this
>> would break existing implementations of MRCP, I see no sufficient reason
>> to change the value.
> 
> Let me give you an example. If I have an SDP class that encodes SDP, the class would not be able to decide whether to write an asterisk "*" or a "1" in the format field, when you invoke it. Writing "1" or "*" will be dependent on the application.
> 
> Then, if you see an SDP body captured by Wireshark or similar, you will need to know which application generated it before you could decided whether the SDP is correct or not. And Wireshark will not be able indicate "format is irrelevant" until it knows which application carried that SDP.
> 
> I haven't heard a good reason for keeping the value "1". So, I am still proposing to reuse the "*".

I believe this has been addressed separately with Robert Sparks.  I will leave the text as-is.

> 
> 
>>> - On Sections 9.4.9, 10.4.8, and 11.4.11, there is no indication of the
>>> possible values of the "media-type-value". I guess you want to say that
>>> these are intended to be MIME types (so far, the word "MIME type" is
>>> not written), and in that case, you should also say that possible
>>> values are any of the values included in the MIME media types registry
>>> maintained by IANA.
>> 
>> I originally referred to these as MIME types. However, a prior reviewer
>> assured me that "media type" was the more proper term (since MIME is
>> about Internet Mail and media types are used for much more than email),
>> so I replaced every instance of "MIME type" with "media type". I would
>> need a very strong argument to change them all back.
> 
> Yes, you are right, the terminology used these days is "media types", so keep on using it.
> 
> 
>>> - Question: In Sections 9.4.21 and 10.4.6, should "1*UTFCHAR" be
>>> included in quotes? It is true that there is no other subfield in the
>>> same header, meaning that there is no intention to parse the text. But
>>> somehow I feel safer if you enclosed the text in quotes. Also, remember
>>> that this text is coming from other protocol beyond your control, so
>>> you never know, for example, if the other protocol is going to add CRLF
>>> or something weird that will crash the recipient of the header.
>>> 
>>> Note that the resolution of this issue should also be applied to
>>> Section 10.4.6.
>> 
>> I checked with my engineer implementing this. We don't see how this is
>> any different from, say, "Subject:" in SIP, which also allows unquoted
>> descriptive text, except that MRCP specifically does not allow LWS. Just
>> like for any other descriptive header field that does not allow LWS, if
>> the sender includes a CRLF as content it will be interpreted as an end to
>> the header, quote or no.
>> I do not plan to make a change at this time.
> 
> Ok, it is fine to leave it as is.
> 
> 
>>> 
>>> - Sections 4.2 and 10.6. The text says that if physical security is
>>> provided, one can void TLS and merely used TCP. I have the feeling that
>>> the connection of these two concepts (physical security and lack of
>>> TLS) is not sufficiently justified for the security experts. One could
>>> access the resources of the MRCP server remotely, via a TCP connection,
>>> not using TLS. Or even sniff the network. So, physical security is not
>>> enough for voiding TLS.
>> 
>> Many of the deployments of MRCP are single-box deployments, or
>> deployments contained completely in fixed-topology, few-node, local-area
>> networks in physically-secure rooms. Both of these are situations where
>> neither remote access nor network sniffing are issues unless physical
>> access to machines is compromised, in which case few security models are
>> sufficient. We do not want to require the use of TLS for such deployments.
>> I expect that "the security experts" you mention will express an opinion
>> if there is a problem with this.
> 
> I'm sympathetic with the spirit of the text. But once more, the lack of TLS is not only connected to physical security, as I understood in the draft. I think TLS can be omitted in controlled environments (e.g., not in the public Internet) where both nodes are inside a protected perimeter, for example, preventing access to the MRCP server from remote nodes outside the controlled perimeter.

Now I understand.  The problem is that I have not used the proper wording to describe the environment.  I agree with you and in 4.2 and 4.5 (and linked there from 10.6) will change "physically secure environments" to "controlled environments (e.g., not in the public internet) where both nodes are inside a protected perimeter, for example, preventing access to the MRCP server from remote nodes outside the controlled perimeter".

> 
>>> Nits:
>>> ====
>>> 
>>> 
> 
>>> - It would be good to have numbers in those tables in Section 5.4. I
>>> mean, there should be a caption saying "Table 1: Success 2xx response
>>> codes".
>> 
>> I am using XML2RFC. If I can figure out how to get it to number the
>> tables I will do this.
> 
> The trick is to write an 'anchor' attribute and presumably a 'title' attribute as well, for example:
> 
> <texttable anchor="table_ex" title="IETF Meetings in 2005">
> 
> Source: http://xml.resource.org/xml2rfcFAQ.html#anchor27

I will do this in the next draft.

> 
> 
>>> 
>>> - Sections 13.7.1 and 13.7.2. There are two tokens being registered in
>>> each Section. Can you add an empty line in between these two
>>> registrations (within the same Section) for the sake of readability?
>> 
>> Hmm, XML2RFC did this. If I can find a way to add an empty line I will do so.
>> 
> 
> Try adding an &nbsp; symbol. Or an empty paragraph.

I will do this in the next draft.

> BR,
>       Miguel
> -- 
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain

---

From: Dan Burnett <[email-masked]>
Date: Sun, 30 Oct 2011 21:20:13 -0400

I have removed all but one of your comments below.  This comment had not yet been addressed.  With this reply I believe I have addressed all of your comments.  If you find that I have missed one please let me know.

-- dan

On May 3, 2011, at 2:39 AM, Miguel A. Garcia wrote:

> 
> - Section 13.1.6 describes a mechanism where vendor-specific extensions use the reverse DNS mechanism, for example., "com.example.foo". Then, if the vendor-specific extension is connected to DNS to avoid clashes in names, why is there a need for an expert review policy prior to its registration? I see a contradiction in having a self-managing registry by avoiding clashes due to the connection to DNS, and then having anything else than a volunteer registry.
> 

In the next draft I will replace "Expert Review" with "First Come First Served".

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 31 Oct 2011 09:54:00 +0100

Hi Dan.

First, I believe I agree with all your previous comments. Thanks for addressing it.

Now, back to this comment related to the IANA registration. See below.

On 31/10/2011 2:20, Dan Burnett wrote:
> I have removed all but one of your comments below.  This comment had
> not yet been addressed.  With this reply I believe I have addressed
> all of your comments.  If you find that I have missed one please let
> me know.
> 
> -- dan
> 
>> - Section 13.1.6 describes a mechanism where vendor-specific
>> extensions use the reverse DNS mechanism, for example.,
>> "com.example.foo". Then, if the vendor-specific extension is
>> connected to DNS to avoid clashes in names, why is there a need for
>> an expert review policy prior to its registration? I see a
>> contradiction in having a self-managing registry by avoiding
>> clashes due to the connection to DNS, and then having anything else
>> than a volunteer registry.
>> 
> 

This does not solve my concern. My concerns is why do you need at the same time:

a) a self-managed registry, by linking reversed DNS names to features

b) an IANA-controlled registry.

There is a redundancy here. The goal of both is to avoid clashes of different features with the same name. If you need an IANA registry, then features do not need to be linked with their DNS names. If you need a reversed DNS names for the features, then their names are self-managed and need not be maintained by IANA. 

So, I still do not understand what you are trying to achieve.

BR,

      Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Dan Burnett <[email-masked]>
Date: Mon, 31 Oct 2011 07:44:58 -0400

Since we are down to only this one comment we can just top-reply :)

The reason we are using this syntactic structure is because that is what implementers of MRCPv1 are already used to.  It is a convenient way to distinguish among different vendors' parameters.

However, the registry is to ensure there are no conflicts.  Merely recommending that vendors use a particular syntax does not ensure that they will do so.  A (public) registry does, at least insofar as making it public when they violate the recommendation.

-- dan

---

From: Eric Burger <[email-masked]>
Date: Mon, 31 Oct 2011 08:18:37 -0400

Now I get it.

Let me put it this way: we can create a protocol parameters space and ask IANA to create a registry full of opaque strings that happen to look like DNS names. Collisions are avoided because IANA manages these opaque strings that look like DNS names. Or, we can use DNS names and ask IANA to do their day job of ensuring that DNS names are unique, which they are.

Therefore, simply saying MRCPv2 will use reverse DNS names is sufficient to ensure a unique vendor name space. If there is a collision, we can let ICANN run the full domain name dispute resolution process. No need to get the IESG or an IETF expert involved.

I vote to simply use reverse DNS names.

---

From: Eric Burger <[email-masked]>
Date: Mon, 31 Oct 2011 09:46:34 -0400

Miguel -
One thing I would like to be clear on. We do want a registry to encourage interoperability. By saying "use reverse DNS names" I do not mean "don't have a registry." Using reverse DNS names is a sufficient mechanism for avoiding naming collisions in the header space. However, avoiding collisions does not mean we foster interoperability.

The reason we want a registry is we want to encourage developers of proprietary extension to document them. By having some documentation out there, the hope is people will learn from each other and hopefully, if something sticks, we can later do some standards track work. 

We did not mandate registration of an extension to use it. There is no protocol police, so there is no point mandating something that one cannot test. Using reverse DNS name space does give us a high probability of non-collisiion.

Likewise, we did not say, "Developers MAY register proprietary headers." That gives people the easy out, and then we get no documentation benefits of the registry.

One thing I would offer to additionally lower the bar on registration with the goal of improving registrations is to drop the requirement that the documentation for the header be published as an RFC. However, I would leave that determination up to the IESG.

Does this work for you?
--
- Eric

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 31 Oct 2011 15:35:30 +0100

You know my opinion. I don't buy Dan's argument of using the IANA 
registration for avoiding some syntax violation. A registry won't avoid it.

/Miguel

On 31/10/2011 13:18, Eric Burger wrote:
> Now I get it.
>
> Let me put it this way: we can create a protocol parameters space and
> ask IANA to create a registry full of opaque strings that happen to
> look like DNS names. Collisions are avoided because IANA manages these
> opaque strings that look like DNS names. Or, we can use DNS names and
> ask IANA to do their day job of ensuring that DNS names are unique,
> which they are.
>
> Therefore, simply saying MRCPv2 will use reverse DNS names is
> sufficient to ensure a unique vendor name space. If there is a
> collision, we can let ICANN run the full domain name dispute
> resolution process. No need to get the IESG or an IETF expert
> involved.
>
>> The reason we are using this syntactic structure is because that is
>> what implementers of MRCPv1 are already used to.  It is a convenient
>> way to distinguish among different vendors' parameters.
>>
>> However, the registry is to ensure there are no conflicts.  Merely
>> recommending that vendors use a particular syntax does not ensure
>> that they will do so.  A (public) registry does, at least insofar as
>> making it public when they violate the recommendation.
>>
>> -- dan
>>
>>
>>>> I have removed all but one of your comments below.  This comment
>>>> had not yet been addressed.  With this reply I believe I have
>>>> addressed all of your comments.  If you find that I have missed
>>>> one please let me know.
>>>>
>>>> -- dan
>>>>
>>>>> connected to DNS to avoid clashes in names, why is there a
>>>>> need for an expert review policy prior to its registration? I
>>>>> see a contradiction in having a self-managing registry by
>>>>> avoiding clashes due to the connection to DNS, and then having
>>>>> anything else than a volunteer registry.
>>>>>
>>>>
>>> There is a redundancy here. The goal of both is to avoid clashes
>>> of different features with the same name. If you need an IANA
>>> registry, then features do not need to be linked with their DNS
>>> names. If you need a reversed DNS names for the features, then
>>> their names are self-managed and need not be maintained by IANA.
>>>
>>> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain
>>
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 31 Oct 2011 15:46:56 +0100

Hi Eric:

Although this is a laudable effort, you won't get the expected results.

First, because the registry does not require a specification. The policy 
(last thing we heard) is First Come First Served, and does not require a 
specification.

Second, a publicly available specification is something that companies 
won't do if they don't want to disclose their own extensions. Instead, 
they will simply create extensions identified by their DNS names, and 
they won't need the IANA registration.

So, I am even more confused than before. If you want to push companies to 
public their specifications, they are not going to do it because you say 
it in a standards document. IANA won't help you.

/Miguel

On 31/10/2011 14:46, Eric Burger wrote:
> Miguel - One thing I would like to be clear on. We do want a registry
> to encourage interoperability. By saying "use reverse DNS names" I do
> not mean "don't have a registry." Using reverse DNS names is a
> sufficient mechanism for avoiding naming collisions in the header
> space. However, avoiding collisions does not mean we foster
> interoperability.
>
> The reason we want a registry is we want to encourage developers of
> proprietary extension to document them. By having some documentation
> out there, the hope is people will learn from each other and
> hopefully, if something sticks, we can later do some standards track
> work.
>
> We did not mandate registration of an extension to use it. There is no
> protocol police, so there is no point mandating something that one
> cannot test. Using reverse DNS name space does give us a high
> probability of non-collisiion.
>
> Likewise, we did not say, "Developers MAY register proprietary
> headers." That gives people the easy out, and then we get no
> documentation benefits of the registry.
>
> One thing I would offer to additionally lower the bar on registration
> with the goal of improving registrations is to drop the requirement
> that the documentation for the header be published as an RFC. However,
> I would leave that determination up to the IESG.
>
> Does this work for you? -- - Eric
>
>
>> Let me put it this way: we can create a protocol parameters space
>> and ask IANA to create a registry full of opaque strings that happen
>> to look like DNS names. Collisions are avoided because IANA manages
>> these opaque strings that look like DNS names. Or, we can use DNS
>> names and ask IANA to do their day job of ensuring that DNS names
>> are unique, which they are.
>>
>>> The reason we are using this syntactic structure is because that
>>> is what implementers of MRCPv1 are already used to.  It is a
>>> convenient way to distinguish among different vendors'
>>> parameters.
>>>
>>> that they will do so.  A (public) registry does, at least insofar
>>> as making it public when they violate the recommendation.
>>>
>>> -- dan
>>>
>>>
>>>>> I have removed all but one of your comments below.  This
>>>>> comment had not yet been addressed.  With this reply I believe
>>>>> I have addressed all of your comments.  If you find that I
>>>>> have missed one please let me know.
>>>>>
>>>>> -- dan
>>>>>
>>>>>> - Section 13.1.6 describes a mechanism where
>>>>>> vendor-specific extensions use the reverse DNS mechanism,
>>>>>> for example., "com.example.foo". Then, if the
>>>>>> vendor-specific extension is connected to DNS to avoid
>>>>>> clashes in names, why is there a need for an expert review
>>>>>> policy prior to its registration? I see a contradiction in
>>>>>> having a self-managing registry by avoiding clashes due to
>>>>>> the connection to DNS, and then having anything else than a
>>>>>> volunteer registry.
>>>>>>
>>>>>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Eric Burger <[email-masked]>
Date: Mon, 31 Oct 2011 11:24:32 -0400

This is an area where I think we are violently agreeing.

We do not require a specification. That meets FCFS requirements. To make a no-registration-required policy work, we need a self-organizing mechanism that avoids conflicts. Reverse DNS names seems to fit this bill.

While we do not require a specification, we do ENCOURAGE publications of specifications. To make that sensible, and to have a place to refer to published specifications, we are establishing a registry.

IANA has gotten really good at establishing registries. It no longer takes months or years for them to set one up. Moreover, this is the lowest-involvement kind of registry for them to run, so it is low impact on their operations. [These are two important items for me to consider with my IAOC hat on.]

If we are getting into a dogmatic or religious discussion, we are more than willing to give up on asking for a registry that might improve long-term interoperability for the short term goal of getting MRCPv2 published. Even the ITU-T is waiting for this document to become an RFC.

Thanks.

On Oct 31, 2011, at 10:46 AM, Miguel A. Garcia wrote:

> First, because the registry does not require a specification. The policy (last thing we heard) is First Come First Served, and does not require a specification.
> 
> Second, a publicly available specification is something that companies won't do if they don't want to disclose their own extensions. Instead, they will simply create extensions identified by their DNS names, and they won't need the IANA registration.
> 
> So, I am even more confused than before. If you want to push companies to public their specifications, they are not going to do it because you say it in a standards document. IANA won't help you.
> 
> /Miguel
>

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 31 Oct 2011 16:36:16 +0100

Hi Eric:

I think I understand your motivation, and I believe you now understand 
that the IANA registry does not warrant any further interoperability. I 
think you have convinced me that the registry may encourage developers to 
publish their specifications, something that, otherwise, it won't happen.

As long as you understand that there is no warranty for success, I have 
no problem. Please proceed with the IANA registry. Make sure that the 
registry itself contains a contact person and a pointer to the published 
specification.

BR,

        Miguel

On 31/10/2011 16:24, Eric Burger wrote:
> We do not require a specification. That meets FCFS requirements. To
> make a no-registration-required policy work, we need a self-organizing
> mechanism that avoids conflicts. Reverse DNS names seems to fit this
> bill.
>
> While we do not require a specification, we do ENCOURAGE publications
> of specifications. To make that sensible, and to have a place to refer
> to published specifications, we are establishing a registry.
>
> IANA has gotten really good at establishing registries. It no longer
> takes months or years for them to set one up. Moreover, this is the
> lowest-involvement kind of registry for them to run, so it is low
> impact on their operations. [These are two important items for me to
> consider with my IAOC hat on.]
>
> If we are getting into a dogmatic or religious discussion, we are more
> than willing to give up on asking for a registry that might improve
> long-term interoperability for the short term goal of getting MRCPv2
> published. Even the ITU-T is waiting for this document to become an
> RFC.
>
> Thanks.
>
>> First, because the registry does not require a specification. The
>> policy (last thing we heard) is First Come First Served, and does
>> not require a specification.
>>
>> Second, a publicly available specification is something that
>> companies won't do if they don't want to disclose their own
>> extensions. Instead, they will simply create extensions identified
>> by their DNS names, and they won't need the IANA registration.
>>
>> So, I am even more confused than before. If you want to push
>> companies to public their specifications, they are not going to do
>> it because you say it in a standards document. IANA won't help you.
>>
>> /Miguel
>>
>>> Miguel - One thing I would like to be clear on. We do want a
>>> registry to encourage interoperability. By saying "use reverse DNS
>>> names" I do not mean "don't have a registry." Using reverse DNS
>>> names is a sufficient mechanism for avoiding naming collisions in
>>> the header space. However, avoiding collisions does not mean we
>>> foster interoperability.
>>>
>>> The reason we want a registry is we want to encourage developers
>>> of proprietary extension to document them. By having some
>>> documentation out there, the hope is people will learn from each
>>> other and hopefully, if something sticks, we can later do some
>>> standards track work.
>>>
>>> We did not mandate registration of an extension to use it. There
>>> is no protocol police, so there is no point mandating something
>>> that one cannot test. Using reverse DNS name space does give us a
>>> high probability of non-collisiion.
>>>
>>> One thing I would offer to additionally lower the bar on
>>> registration with the goal of improving registrations is to drop
>>> the requirement that the documentation for the header be published
>>> as an RFC. However, I would leave that determination up to the
>>> IESG.
>>>
>>>> Let me put it this way: we can create a protocol parameters
>>>> space and ask IANA to create a registry full of opaque strings
>>>> that happen to look like DNS names. Collisions are avoided
>>>> because IANA manages these opaque strings that look like DNS
>>>> names. Or, we can use DNS names and ask IANA to do their day job
>>>> of ensuring that DNS names are unique, which they are.
>>>>
>>>>> The reason we are using this syntactic structure is because
>>>>> that is what implementers of MRCPv1 are already used to.  It
>>>>> is a convenient way to distinguish among different vendors'
>>>>> parameters.
>>>>>
>>>>> However, the registry is to ensure there are no conflicts.
>>>>> Merely recommending that vendors use a particular syntax does
>>>>> not ensure that they will do so.  A (public) registry does, at
>>>>> least insofar as making it public when they violate the
>>>>> recommendation.
>>>>>
>>>>> -- dan
>>>>>
>>>>>
>>>>>>> comment had not yet been addressed.  With this reply I
>>>>>>> believe I have addressed all of your comments.  If you
>>>>>>> find that I have missed one please let me know.
>>>>>>>
>>>>>>> -- dan
>>>>>>>
>>>>>>>> vendor-specific extensions use the reverse DNS
>>>>>>>> mechanism, for example., "com.example.foo". Then, if
>>>>>>>> the vendor-specific extension is connected to DNS to
>>>>>>>> avoid clashes in names, why is there a need for an
>>>>>>>> expert review policy prior to its registration? I see a
>>>>>>>> contradiction in having a self-managing registry by
>>>>>>>> avoiding clashes due to the connection to DNS, and then
>>>>>>>> having anything else than a volunteer registry.
>>>>>>>>
>>>>>>>
>>>>>> There is a redundancy here. The goal of both is to avoid
>>>>>> clashes of different features with the same name. If you
>>>>>> need an IANA registry, then features do not need to be
>>>>>> linked with their DNS names. If you need a reversed DNS
>>>>>> names for the features, then their names are self-managed
>>>>>> and need not be maintained by IANA.
>>>>>>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Eric Burger <[email-masked]>
Date: Mon, 31 Oct 2011 11:37:16 -0400

Thanks!

Dan - got it?

Done.
--
- Eric

On Oct 31, 2011, at 11:36 AM, Miguel A. Garcia wrote:

> Hi Eric:
> 
> I think I understand your motivation, and I believe you now understand that the IANA registry does not warrant any further interoperability. I think you have convinced me that the registry may encourage developers to publish their specifications, something that, otherwise, it won't happen.
> 
> As long as you understand that there is no warranty for success, I have no problem. Please proceed with the IANA registry. Make sure that the registry itself contains a contact person and a pointer to the published specification.
> 
> BR,
> 
>       Miguel
> 
> 
>

---

From: Dan Burnett <[email-masked]>
Date: Mon, 31 Oct 2011 19:40:14 -0400

I think the only change I will have to make is that instead of an RFC defining the value a requester merely needs documentation.