Hi Ben,
thanks for your comments. Answers inline:
Ben Campbell wrote:
Hi,
General comments:
(editorial) Personal pet-peeve: It is much more friendly to the
reader to use the form, "...defined in RFCXXX [8]", than to say
"...defined in [8]." Otherwise they have to keep referring to the
reference section. I realize that is hard to do with
works-in-process, but we could use a descriptive name. (I mention
this in general as it is pervasive to the draft.)
yes, you are probably right. In any case, this is a change we may be
able to do in AUTH48, when all the references have become RFCs. Doing a
global replace should not be a big deal for the RFC editor at that point.
3.
This section defines the new conditions and actions defined by this
specification. This specification does not define any new
transformation.
I am at a loss to understand how transformations would be used at all
for this purpose.
I have clarified that point adding the following sentence at the end of
the first paragraph of Section 3:
However, even though permission documents need to
have a transformation part to comply to the common policy syntax,
effectively, permission documents do not make any use of
transformations.
3.1.1.
The elements <one> and <except> MUST contain a scheme when they
appear in a permission document.
We are talking about the "id" attribute in each of those, correct?
yes. I have clarified it as follows:
The 'id' attribute in the elements <one> and <except> MUST
contain a scheme when these elements appear in a permission document.
Also, is the <many> element permissible in <identity>? I don't
understand how it would be used, particularly since the framework
does not allow wildcarding of identity.
you are right. The framework disallows to wildcard recipient URIs.
However, in the future, there might be use cases for wildcarded
recipients. Therefore, it seems enough forbidding them in the framework.
No need to restrict the syntax of the document format.
In any case, if you feel very strongly about this, I can add a normative
sentence forbidding them in the format as well.
For PUBLISH requests that are authenticated using the SIP Identity
mechanism, the identity of the sender of the PUBLISH request is
equal to the SIP URI in the From header field of the request,
assuming that the signature in the Identity header field has been
validated.
Should we have a normative statement that the signature MUST be
validated?
I believe that the paragraph is clear enough: if the signature is
validated, then the identity is the one in the From header field.
Otherwise, the sender cannot be considered authenticated. However, feel
free to suggest how to modify the paragraph if you think it can be
clarified even further.
P-Asserted-Identity [5], as described in [9]. For PUBLISH requests
that are authenticated using the P-Asserted-Identity mechanism, the
identity of the sender of the PUBLISH request is equal to the
P-Asserted-Identity header field of the request.
Need to mention the P-Asserted-Identity requires the request to have
come from a trusted element.
This part of the document describes where to get the identity from when
using different authentication mechanism; not how to use those
mechanisms. Implementors should check the references specifying those
mechanisms to implement them anyway. So, I do not think we need to
clarify how P-Asserted-Identify works even further.
3.1.2:
The sender condition is matched against the URI of the sender of
the request that is used as input for a translation. Sender
conditions can contain the same elements and attributes as identity
conditions.
does this include the same rules about having a scheme in <exception>
and <one>?
Also, is <many> allowed? It seems to make more sense for <sender>
than for <identity>
no, those rules do not apply to senders. In fact, further down in the
same section, the document explains how to compute a URI from an id
attribute in a <one> or <except> element without scheme.
3.1.2.2
For requests that are authenticated using SIP Digest, the identity
of the sender is set equal to the user and domain part of the SIP
Address of Record (AOR) for the user that has authenticated
why not just the whole SIP AoR? That is, why did we mention user and
domain parts, rather than just take the AoR URI as a whole?
you are right. I have removed "the user and domain part of"
For requests that are authenticated using RFC 3325 [5], the
identity of the sender is equal to the username and domain parts of
the SIP URI in the P-Asserted-ID header field. If there are
multiple values for the P-Asserted-ID header field (there can be
one sip URI and one tel URI [10]), then each of them is used for
the comparisons outlined in [8], and if either of them match a
<one> or <except> element, it is considered a match.
why do we call out user and domain parts, instead of just taking the
URI as a whole?
I have removed " the username and domain parts of" here as well.
3.1.2.3
what are the consequences of being unable to convert the id?
then, no sender will match the <sender> element in the document and the
permission document would be useless.
3.2.1:
The use of the transl-handling URIs seems under-specified to me. The
framework document mentions you can send a SIP PUBLISH or an HTTP
get. In the case of publish, what do you publish? An empty document?
HTTP is easier to figure out, but it is still not explicit. What
about other schema?
Per my previous email addressing your comments on the framework, I have
clarified that point.
Regarding other schemas, what do you have in mind? Being able to provide
SIP and HTTP URIs seems enough for all practical purposes.
4.
Should the two <id> elements be <one> elements instead?
Fixed.
I have posted a working version of the next revision of this draft at:
http://users.piuha.net/gonzalo/temp/draft-ietf-sipping-consent-format-01.txt
Thanks,
Gonzalo
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip