[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sip] WGLC comments for draft-ietf-sipping-consent-format-00

[Oops, sent to SIP by mistake. Resending to SIPPING. Sorry for the duplicate.]


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.)

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.

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?

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.

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?

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.

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>

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?

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?

3.1.2.3

what are the consequences of being unable to convert the id?

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?

4.

Should the two <id> elements be <one> elements instead?















_______________________________________________
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